SPF, DKIM and DMARC setup.
Checked in live DNS.

The summary is the section's first screen and the big picture across all sending domains in six numbers. Each number answers its own question: how many domains there are and where their zones are kept, how many records are already visible in DNS, whether signing keys are on the servers, whether there are reverse DNS records (PTR), and whether the name servers at the registrar match. The tile color shows at once whether all is well: in the example, the red tile is a record changed by hand, and the yellow one is a domain still waiting for its NS change. Choosing a server above the tiles recounts the numbers for that server only. If a tile isn't green, start with the “Needs attention” block below: the same problem is already listed there with a button that takes you to the fix.

Enlarge

• Sending domains — 26 in the example.
• Own NS / provider — where zones are kept: in the example, 24 on your own name servers and 2 at a provider.
• Records visible in DNS — 379 of 396. The tile is red: one domain's record was changed by hand.
• Keys on nodes — 25 of 26 domains already have their signing key on the sending server.
• Addresses with PTR — 25 of 26 addresses have a reverse DNS record.
• Delegation — the name servers at the registrar match for 23 of 24 domains. The tile is yellow: a new domain is still waiting for its NS change.
• Above the tiles — server selection (the numbers are recounted for it), the time of the last check and the “Add domains” button.

The numbers in the screenshot belong to an example infrastructure, not to the module's limits.

The “Needs attention” block is a list of what needs fixing in DNS, starting with what's most dangerous for delivery. It holds only real problems: records changed by hand, extra records in the zone, records not yet visible everywhere, and wrong reverse DNS records. Each row has a button that takes you to the fix: “Export again”, “Open the domain” or “Check in DNS”. This list is a handy place to start your daily domain check: while it isn't empty, some messages may not arrive. A new domain whose records haven't been exported yet isn't listed here: that's a normal setup step, not a problem, and such a domain shows up in the domain table.

Enlarge

• Record changed by hand — in the example, DMARC for secure.corvalis-bank.org was relaxed in the provider panel: DNS has p=none, while the Hub wrote quarantine. The “Export again” button restores the correct value.
• Extra record in the zone — for id.corvalis-bank.org, a second SPF from the previous mailing service was added by hand, and two SPF records on one domain break mail checks. “Open the domain” takes you to where the extra is removed.
• Record not visible everywhere — promo.tidewaymedia.net is going through a key change: Google already sees the new record, Cloudflare doesn't yet. “Check in DNS” checks again.
• Reverse DNS points to another name — for send.lumaclub.net the hosting provider left its standard record. It can only be changed by a request to the hosting provider — the Hub just checks it.
• What isn't here — a new domain whose records haven't been exported yet: that's a normal setup step, not a problem.

The domain table is the working list of all your sending domains: one row per domain. A row shows which server and address it sends from, where the zone is kept, how many records are visible in DNS, whether the DKIM signing key is ready, whether there's a reverse DNS record and when the domain was checked. Domains with problems are at the top and the rest are alphabetical, so whatever hurts delivery doesn't get lost among healthy rows. Filters by zone location and by problem help you pick out the group you need quickly. In the example, all 15 records of the new offers.lumaclub.net haven't been exported yet: you tick such a domain in the table and export its records as the next step.

Enlarge

• Domain — the name and the records' time to live (TTL).
• Node and address — the sending server and the IP address the domain is assigned to.
• Zone — on your own name servers or in a provider's panel (DNSmanager in the example).
• Records — how many of the required records are visible in DNS, and what's wrong: drifted, not exported, not visible everywhere, extra in the zone.
• Signing key — the key's name and state: deployed or awaiting publication.
• Reverse DNS and checked — whether there's a PTR and whether it matches, and how long since the last check.
• Filters — by zone location and by problem; they can be combined.

Bulk actions help when you have many domains and need to do the same thing for a whole group. Tick several domains and run one action for all of them at once: export records, check them in DNS or issue keys. The line above the buttons tells you in advance where the records will go — to your own name servers or to a provider's panel. If you tick domains from different places, the Hub creates a separate task for each place, and each task's progress is shown in a console. A typical case: after adding a group of new domains, export all their records at once, then check in one go whether they're visible in DNS.

Enlarge

• Ticked domains — how many are selected and where their zones are kept.
• Where the records will go — to your own name servers or to a provider's panel — shown before you start.
• Separate tasks — for domains in different places, one task per place.
• Console — each task has its own run log.

The add-domains form: new sending domains are connected in one step, and you can add several at once. Choose the sending server, where the zone will be kept, and the IP address to assign the domains to; below, set the record settings — DKIM selector and key length, DMARC policy and TTL. The Hub builds the records and issues the signing key, but doesn't send them anywhere: exporting is a separate step that you start. This way you can review the record set before it reaches DNS. Once added, the domain appears in the domain table, and its records are exported from the domain card or with a bulk action for the whole group at once.

Enlarge

• Server, zone location and address — where to assign the domains and where their zone will be kept.
• Domains — you can add several at once.
• Signing key — name (selector) and length; 2,048 bits by default.
• DMARC and TTL — the domain policy and the records' time to live.
• Advanced — the address for DMARC reports, other SPF sources, how addresses are written in SPF, and the smtp, imap, pop service names.

A 2,048-bit DKIM key is used by default.

The domain card brings together everything about one sending domain on one page. At the top: where the zone is kept, the server and address, the signing key and the records' time to live (TTL). The buttons next to it act on this domain only: export the records, check them in DNS, deploy the key to the server, change where the zone is kept, or remove the domain. That way you can't accidentally touch anything else — this is the place to go when you need to fix one problem from the “Needs attention” list. If the check showed a record isn't visible everywhere, you check it again right here with the “Check in DNS” button — other domains aren't affected.

Enlarge

• Header — domain, zone location, server, address, signing key and TTL.
• “Export records” — send the records to where the zone is kept.
• “Check in DNS” — ask Google and Cloudflare whether the records are visible.
• “Deploy key to node” — put the signing key on the sending server.
• “Where the zone lives” and “Remove domain” — change where the zone is kept, or delete the domain.

Four key answers about a domain that tell you whether it's ready to send mail. Are the records visible in DNS, is the DKIM signing key ready, do the name servers at the registrar match, and is there a PTR reverse DNS record. They show right away what setup step the domain is at and what's left to do. In the example a key change is under way: the new key is still awaiting publication, so messages are signed with the previous one, and one of 16 records isn't visible everywhere yet. If any of the four answers shows a problem, further down the same page are the zone records table and the log of the last check: they show exactly which record is lagging.

Enlarge

• Records — in the example 15 of 16 are visible, one isn't visible everywhere yet.
• Signing key — the new key hub2610 is awaiting publication and isn't on the server yet — for now messages are signed with the previous hub2604.
• Delegation — matches: the registrar has ns1 and ns2.zonecarrier.net.
• Reverse DNS — present and pointing to the domain itself — the name the server introduces itself with to mailbox providers.

In the example the new selector is awaiting publication, while the previous key keeps signing.

All DNS records of the domain's zone in one table — what the Hub has built for this domain's mail. Each record has its value, a note on what it's for, its time to live and its state: whether it's visible in DNS. You can filter records by purpose — mail, signing, proxy — and the “Compare with zone” button compares them with what's in DNS right now. At the bottom the Hub suggests the exact value for the address's reverse DNS record: it's set by the address provider, not the Hub. If a record was changed by hand in the provider's panel, you see the mismatch with the Hub's value here, and the “Export records” button in the card header restores the correct value.

Enlarge

• Type and name — A, MX, TXT (SPF, DMARC), DKIM and service subdomains.
• Value and purpose — what's written and why the record is needed.
• SPF — both server addresses are written as one short subnet entry that doesn't cover anyone else's addresses.
• TTL and state — time to live and whether the record is visible in DNS.
• Filters — all, mail, signing, proxy; the “Compare with zone” and “Custom record” buttons.
• Reverse DNS — a hint on what PTR value to request from the address provider.

DNS zone settings are the rules the Hub uses to build this domain's records. Here you change the signing key's name and length, the DMARC policy and report address, the records' time to live, extra SPF sources and the smtp, imap, pop service names. After a change, the records are rebuilt by the new rules with the “Rebuild records” button. A key with the same name isn't reissued in the process: there's a separate action for changing the DKIM key. For example, if you need to tighten DMARC or add another sending source to SPF, you change the rule here, then rebuild the records and export them to the zone.

Enlarge

• Signing key — name (selector) and length.
• DMARC — policy and report address.
• TTL — the records' time to live.
• SPF — extra sources and how addresses are written.
• Service names — smtp, imap, pop.
• “Rebuild records” — build the set again. A key with the same name isn't reissued — changing the key is done separately.

This is what a DKIM key change looks like in the zone records. The “signing” filter shows the records of both keys — the previous hub2604 and the new hub2610 — and whether they're visible in DNS. Google already sees the new key, but Cloudflare doesn't yet, so messages are still signed with the previous key. Signature checks at mailbox providers pass without errors, and the Hub switches signing to the new key only after its record becomes visible. Another MTA's public key is added when the domain signs mail not only through the Hub: then its record must also be in DNS next to the Hub's keys.

Enlarge

• Previous key hub2604 — visible in DNS and signing messages.
• New key hub2610 — not visible everywhere: Google already sees it, Cloudflare doesn't yet.
• Transition — the Hub switches signing to the new key only after its record becomes visible.

All of the domain's DKIM signing keys and their state on one screen. The previous key is being replaced but stays deployed on the server, and the Hub keeps its record in DNS until it expires from DNS servers' caches; the new key is awaiting publication. Here you can also reissue a key under a new name or add a public key from another MTA. For PowerMTA, the private part of the key is a file on the server — the path is shown, and the key can be displayed and downloaded; for MailerQ, it's stored in the cluster database. Usually there's nothing to do here: just wait until Cloudflare sees the new record too, and run the check again. Both keys and their state are also listed among the domain's signing keys.

Enlarge

• Previous key — “being replaced”: its record stays in DNS until the set time.
• New key — “awaiting publication”.
• Private part — for PowerMTA, a file on the server — the path is shown, and the key can be displayed and downloaded; for MailerQ, stored in the cluster database.
• Reissue — a new key is issued under a new name.
• Another MTA's key — a public key can be added separately.

The previous DNS record is kept for a period tied to the TTL.

The log of the domain's last task shows exactly what the Hub did with the zone and how it ended. In the example it's the check after a key change: for each record you see what Google and Cloudflare answered, and the overall result “15 of 16 visible”. If the task covered several domains, the card shows the shared header and the part that belongs to this domain. The log shows which record still isn't visible everywhere, and you can run the check again. If a record isn't visible at either Google or Cloudflare, it's no longer a delay: export that record again from the domain card and check once more.

Enlarge

• Records — each record and what Google and Cloudflare answered for it.
• Result — in the example, “15 of 16 visible”.
• Shared task — a task for several domains has a shared header and this domain's part.

Here you choose where the domain's zone is kept: on your own name servers running PowerDNS, or in a DNS provider's panel through a connected DNS account. You can change the place — the records move there with the next export. To move to your own name servers, you need to change the NS at the registrar: the Hub shows you what to enter and checks whether the delegation matches. The Hub itself changes nothing at the registrar — the domain owner does that. You move a zone when transferring it from a provider's panel to your own name servers or back; more on this on the “Name servers” and “DNS accounts” pages.

Enlarge

• Your own name servers — the zone is kept on your server running PowerDNS.
• Provider panel — through a connected DNS account.
• Changing the place — the records move with the next export.
• NS at the registrar — the Hub shows the values needed and checks the delegation.

Every night the Hub compares the whole zone and finds records it didn't create — for example, leftovers from a previous mailing service. In the example, the provider's zone for id.corvalis-bank.org has a second SPF next to the Hub's record, and two SPF records on one domain break mail checks. Ticked records are deleted with one button; before deleting, the Hub compares the zone once more and restores its own records. A deletion in DNS can't be undone, so first make sure no other service needs the record. If the domain used to send through another service, look here first: old SPF records and signing keys often stay in the zone after you switch email platforms.

Enlarge

• Record found — v=spf1 include:_spf.oldmailer.example ~all.
• Tick and delete — extras are deleted with one button.
• Before deleting — a deletion in DNS can't be undone, so the Hub compares the zone once more and restores its own records.

Check what the records are for before deleting: this changes a live DNS zone.

DNS for sending through proxies: if a domain sends mail through proxies, it needs separate records. For each proxy the Hub creates a subdomain pointing to the proxy's external address, and adds the proxy addresses to the domain's SPF. This is the name the server introduces itself with to the mailbox provider when sending through the proxy. In the example news.lumacart-shop.com has five proxies, and their records are highlighted in yellow: a domain can have more of them than all the other records combined. The short time to live — 300 seconds — lets you change a proxy address quickly: the new value spreads through DNS servers' caches in minutes, not hours.

Enlarge

• Five proxies in the example — px-01…px-05 for news.lumacart-shop.com.
• A subdomain for each proxy — pointing to the proxy's external address.
• Short time to live — 300 seconds.
• SPF — proxy addresses are added to the domain's SPF.
• Highlighting — proxy records are highlighted in yellow: a domain can have more of them than all the others combined.