The finance manager forwards you a message and asks how it got through. It appears to come from the CEO, it carries the company domain in the From line, and it asks for a bank detail change on an invoice that is genuinely outstanding.<\/p>\n\n\n\n
So you check the zone. There is an MX record. There is an SPF record. There is a DKIM key published under a selector. There is a DMARC record. You paste the domain into three free checkers and every one of them lights up green.<\/p>\n\n\n\n
Everything is configured. The domain is still trivially spoofable.<\/p>\n\n\n\n
This is the failure mode that makes business email DNS worth writing about. It is not that people forget to publish records. It is that publishing a record and enforcing a policy are different acts, the checkers reward the first one, and nothing anywhere in DNS will tell you that you stopped halfway.<\/p>\n\n\n\n
What follows is what each of the four records actually does, what breaks when it is wrong, the domain architecture decision that stops the problem recurring, and an order of operations that gets you to enforcement without losing legitimate mail on the way.<\/p>\n\n\n\n
Almost every confused email ticket traces back to one misunderstanding: people treat these four records as a single feature called “email setup.” They are two unrelated systems that happen to share a zone file.<\/p>\n\n\n\n
The consequence is blunt. If inbound mail is not arriving, editing SPF cannot help and never will. If your domain is being spoofed, a perfect MX configuration contributes nothing. It is common to see an afternoon spent rewriting an SPF record for a problem that lived entirely in a mail routing rule.<\/p>\n\n\n\n
A third job hides inside the second, and it is the one people skip. SPF and DKIM only produce evidence: this server was authorized, this content was signed by this domain. Neither tells a receiving server what to do when the evidence is missing. Only DMARC does, through its policy tag, and that tag is the single enforcement dial in the whole arrangement.<\/p>\n\n\n\n
An MX record carries exactly two values: a preference number and a hostname. Lower preference numbers are tried first. Equal preference numbers let a sender spread load across the listed hosts, which is how most hosted mail providers publish theirs.<\/p>\n\n\n\n
dig +short MX example.com<\/code><\/pre>\n\n\n\nThe hostname side has two constraints panels will happily let you violate. The target must be a name resolving to A or AAAA records, not an IP typed into the field, and it must not point at a CNAME. Some panels accept an IP and quietly invent a hostname behind the scenes, which works until you move providers and find the record you thought you published is not the one that exists.<\/p>\n\n\n\n
If a domain has no MX record at all, the SMTP specification tells senders to fall back to its A or AAAA address. On a business domain that is your web server. The connection times out or is refused, and the sender queues and retries for days before anyone sees a bounce. The mail is not rejected; it is late, sometimes by a working week.<\/p>\n\n\n\n
And subdomains do not inherit MX records from the parent. If example.com<\/code> has MX records, mail.example.com<\/code> does not. It falls back to its own A record, or to nothing.<\/p>\n\n\n\nNull MX for domains that should never receive mail<\/h3>\n\n\n\n
Most businesses own more domains than they use for mail: typo-squat defenses, old brand names, a marketing microsite, the domain from the company they acquired. RFC 7505 defines a way to say “this domain accepts no mail” explicitly, using a single MX record with preference 0 and a target of a lone dot.<\/p>\n\n\n\n
example-parked.com. 3600 IN MX 0 .<\/code><\/pre>\n\n\n\nA conforming sender sees this and rejects immediately instead of falling back to the A record and retrying for days. The bigger benefit is backscatter: when someone forges a return address at a domain of yours, bounce messages get aimed at it. A null MX turns those into an instant rejection at the sender’s end.<\/p>\n\n\n\n
One rule attached to this: a domain advertising a null MX must not publish any other MX records. It is the whole set or nothing.<\/p>\n\n\n\n
One operational note: drop MX TTLs to a few minutes before a mail migration and raise them afterwards. A low TTL costs a little query volume. A high TTL during a cutover costs you mail delivered to a server you already decommissioned, with no error anywhere to tell you. Per-record TTL control and fast propagation matter here, which is why I would rather do a cutover on something like Cloudflare than a registrar’s default panel.<\/p>\n\n\n\n
SPF: an authorization list with a hard budget<\/h2>\n\n\n\n
SPF is a TXT record at the domain apex that begins with v=spf1<\/code> and lists the systems allowed to send with your domain in the envelope sender. Publish two of them and you have published none: the result is a permanent error, which receivers treat as a failure.<\/p>\n\n\n\ndig +short TXT example.com<\/code><\/pre>\n\n\n\nThe constraint everyone eventually hits is the lookup budget. Evaluation is capped at ten DNS-querying mechanisms. The terms that count are include<\/code>, a<\/code>, mx<\/code>, ptr<\/code>, exists<\/code> and redirect<\/code>, and the count follows nested includes all the way down, so one vendor include:<\/code> can carry four lookups inside it. Literal ip4<\/code> and ip6<\/code> ranges cost nothing, and neither does all<\/code>.<\/p>\n\n\n\nExceed ten and evaluation stops with a permanent error. It does not fail open. It does not keep counting and pass anyway.<\/p>\n\n\n\n
There is a second, quieter limit: void lookups, meaning queries that return nothing. Implementations are told to cap those at two. This is the one that bites long after you stop paying attention, because the trigger is a vendor you cancelled whose include:<\/code> target eventually stopped resolving. Your record did not change. Your mail started failing anyway.<\/p>\n\n\n\nOver budget, the honest options are to drop vendors you no longer use, replace lookup-heavy mechanisms with the literal IP ranges they resolve to, or move senders onto their own subdomains so each gets a fresh budget. Flattening services that resolve includes and keep the record updated do work, but understand the trade: you have taken on a dependency that must track your vendors’ IP changes, and cloud senders rotate ranges.<\/p>\n\n\n\n
Why hard fail is not automatically the safer choice<\/h3>\n\n\n\n
SPF records end with a qualifier on all<\/code>. Soft fail is ~all<\/code>; hard fail is -all<\/code>. The instinct is that hard fail is the stricter, more secure choice, and it is, but the DMARC specification calls out a specific cost that is easy to miss.<\/p>\n\n\n\nSPF is evaluated early in the SMTP conversation. A hard fail can get a message rejected before the message body is ever transmitted, which means before the From header is visible and before DMARC is evaluated at all. A message that would have passed DMARC on an aligned DKIM signature can be rejected purely on SPF.<\/p>\n\n\n\n
Messages rejected that early never reach the DATA phase, so they never appear in your DMARC aggregate reports. You lose the failure and the evidence of the failure in the same move.<\/p><\/blockquote>\n\n\n\n
That is the argument for staying on ~all<\/code> while you are still discovering who sends as you, and moving to -all<\/code> once your reports have gone quiet. On a parked domain with no legitimate senders at all, publish v=spf1 -all<\/code> immediately; there is nothing to discover.<\/p>\n\n\n\nOne more thing SPF does not do, and this is the root of most DMARC confusion. SPF authenticates the envelope sender, the address in the SMTP MAIL FROM<\/code> command. Your recipients never see that address. They see the From header, which SPF does not check at all.<\/p>\n\n\n\nDKIM: the signature that survives a forward<\/h2>\n\n\n\n
DKIM adds a cryptographic signature over selected headers and the message body. The public key lives in DNS under a selector, in the form selector._domainkey.example.com<\/code>, and the signature header names both the selector and a signing domain in its d=<\/code> tag.<\/p>\n\n\n\ndig +short TXT s1._domainkey.example.com<\/code><\/pre>\n\n\n\nThat d=<\/code> value is the part that matters and the part that gets ignored. A message can carry a perfectly valid signature from your provider’s own domain. It verifies. It proves nothing about you, because the identity it asserts is theirs. Completing your provider’s domain authentication step, the one that has you publish records under your own zone, is what moves d=<\/code> onto your domain.<\/p>\n\n\n\nAlgorithms and key size<\/h3>\n\n\n\n
The rules here are settled. Signers must use rsa-sha256. The older rsa-sha1 must not be used for signing or verifying, and signatures using it fail permanently. Keys must be at least 1024 bits and should be at least 2048. Verifiers are required to reject anything under 1024 outright.<\/p>\n\n\n\n
A useful field heuristic follows from a DNS quirk. A single TXT character string maxes out around 255 characters, and a 2048-bit RSA key does not fit in one. So if your DKIM record comes back from dig<\/code> as one quoted string, it is probably 1024-bit; split into two concatenated strings, probably 2048. A hint rather than proof, but it takes two seconds.<\/p>\n\n\n\nAn Ed25519 signing algorithm is also defined for DKIM, with compact keys and good cryptographic properties, but support across platforms and verifiers is still uneven. RSA with SHA-256 remains the safe universal choice unless you sign with both.<\/p>\n\n\n\n
Rotating a key without breaking anything<\/h3>\n\n\n\n
Never edit a DKIM key in place. Mail already in flight, in a queue, or sitting in a mailing list’s outbound spool was signed with the old key, and overwriting the record invalidates all of it retroactively.<\/p>\n\n\n\n
- Publish the new key under a new selector name and confirm it resolves.<\/li>
- Switch the signing platform to the new selector.<\/li>
- Wait out the longest plausible delivery delay, which is days rather than hours if mailing lists are involved.<\/li>
- Remove the old selector record.<\/li><\/ol>\n\n\n\n
DKIM has one property SPF does not, and it decides your architecture later. A signature travels with the message. When mail passes through a forwarder, a role alias or a mailing list, the connecting IP is no longer yours and SPF fails; the DKIM signature usually still verifies. This is why the DMARC specification states that domains publishing a reject policy must not rely on SPF alone and must apply valid DKIM signatures.<\/p>\n\n\n\n
DMARC: connecting the visible domain to the proof<\/h2>\n\n\n\n
DMARC is a TXT record at _dmarc.example.com<\/code>. It asks one question that neither SPF nor DKIM asks: does the domain your recipient can actually see match the domain that proved itself?<\/p>\n\n\n\ndig +short TXT _dmarc.example.com<\/code><\/pre>\n\n\n\nThat match is called alignment. Relaxed alignment, the default, accepts any domain sharing the same organizational domain, so mail.example.com<\/code> aligns with example.com<\/code>. Strict requires them to be identical. A message passes DMARC if either SPF or DKIM passes and<\/em> the domain that passed aligns with the From header. One aligned mechanism is enough. Both passing while neither aligns is a fail, and that is the most common cause of “but all my checkers are green.”<\/p>\n\n\n\nThe tags worth knowing<\/h3>\n\n\n\np<\/code> is the policy for the domain itself: none<\/code>, quarantine<\/code> or reject<\/code>. Omit it and the record is treated as p=none<\/code>.<\/li>sp<\/code> sets a separate policy for existing subdomains.<\/li>np<\/code> sets a policy for subdomains that do not exist in DNS at all. This is the anti-spoofing tag most zones are missing.<\/li>rua<\/code> is where aggregate reports are sent. Without it you get no reports, and without reports you are guessing.<\/li>adkim<\/code> and aspf<\/code> switch the two alignment modes from relaxed to strict.<\/li>t=y<\/code> is test mode. It tells receivers to apply one level below your stated policy, so a record saying reject behaves as quarantine, and quarantine behaves as none.<\/li><\/ul>\n\n\n\nThe DMARC specification has been rewritten and promoted onto the IETF standards track as RFC 9989, with aggregate and failure reporting split into RFC 9990 and RFC 9991, obsoleting the original RFC 7489. Existing records keep working and still begin with v=DMARC1<\/code>, so nothing is urgent. Three things are worth acting on at your next zone edit.<\/p>\n\n\n\nThe pct<\/code>, rf<\/code> and ri<\/code> tags are gone. Unknown tags are ignored rather than treated as errors, so leaving them does no damage, but pct<\/code> no longer means anything and the staged rollout it was used for is now t=y<\/code>.<\/p>\n\n\n\nThe Public Suffix List is no longer how receivers determine your organizational domain. They now walk up the DNS hierarchy looking for a DMARC record at each level, capped at eight queries. For a two-label domain this changes nothing. For a deep subdomain hierarchy it can resolve differently than the old method did, and a name deeper than eight labels will never have its policy record found by the walk. If you run a complex namespace, publish an explicit record at the exact name rather than relying on inheritance.<\/p>\n\n\n\n
And if two DMARC TXT records are returned for the same name, both are discarded. A duplicate is not a merge or a tiebreak. It is the same as having none.<\/p>\n\n\n\n
Reading the reports<\/h3>\n\n\n\n
Aggregate reports arrive as gzipped XML, typically once a day per reporting provider. They are technically human-readable and practically not, especially once a dozen providers are reporting on a domain with several sending services.<\/p>\n\n\n\n
Two honest choices. Parse them yourself, which is a small satisfying project that gives you exactly the view you want. Or point rua<\/code> at a hosted processor; Dmarcian, Valimail and PowerDMARC all do this competently, with entry tiers sufficient for one domain. The trade is that you are sending metadata about your mail flows to a third party and inheriting their retention terms. Read those terms first in a regulated environment.<\/p>\n\n\n\nDomain architecture: the decision that stops this recurring<\/h2>\n\n\n\n
Everything above is records. This part is structure, and it is what separates a zone that stays correct from one that quietly rots.<\/p>\n\n\n\n
Put each sending stream on its own subdomain. People mail from the apex. Marketing sends from something like news.example.com<\/code>. Transactional and application mail sends from mail.example.com<\/code> or similar. Each subdomain gets its own SPF record, its own DKIM selectors, and its own DMARC record if you want a different policy there.<\/p>\n\n\n\n- Each subdomain gets a fresh ten-lookup SPF budget, which is usually what forced the decision in the first place.<\/li>
- A marketing platform that gets breached or blocklisted does not drag your invoices and password resets down with it.<\/li>
- Reputation is scoped. Bulk sending and one-to-one business mail get judged separately, which is what you want, because they behave nothing alike.<\/li>
- You can hold the apex at a strict policy while a subdomain is still being brought into line.<\/li><\/ul>\n\n\n\n
The cost is more records to maintain and one more thing to explain to whoever inherits the zone. It is worth it the first time a vendor migration happens and you only have to touch one subdomain.<\/p>\n\n\n\n
Then close the gaps. Every domain that never sends and never receives should carry a null MX, an SPF record of v=spf1 -all<\/code>, and DMARC at p=reject<\/code>. Three records, five minutes, and the domain leaves the pool of things abusable in your name. Add np=reject<\/code> on live domains too, because an attacker does not need a subdomain to exist in order to put it in a From header.<\/p>\n\n\n\nRolling it out without losing mail<\/h2>\n\n\n\n
The order matters, because each step depends on evidence produced by the one before it.<\/p>\n\n\n\n
- Inventory every sender.<\/strong> Mailbox provider, CRM, helpdesk, billing system, marketing platform, monitoring alerts, and the tool a department signed up for without telling anyone. This list is always longer than expected and it is the highest-value step here.<\/li>
- Fix MX first,<\/strong> with a low TTL if you are migrating. Inbound is what people notice within minutes.<\/li>
- Publish SPF within budget,<\/strong> ending in
~all<\/code> for now. Count lookups before publishing, not after mail fails.<\/li>- Get DKIM signing on your own domain<\/strong> for every stream. Verify
d=<\/code> in the headers of a real received message rather than trusting a dashboard.<\/li>- Publish DMARC at
p=none<\/code> with a rua<\/code> address.<\/strong> This changes nothing about delivery and starts the flow of evidence.<\/li>- Read reports for several weeks.<\/strong> Longer if you have quarterly patterns like invoicing runs or annual renewals, which is exactly the mail you cannot afford to break.<\/li>
- Move to
p=quarantine<\/code><\/strong> once every remaining failure is one you recognize as spoofing. Use t=y<\/code> for a softer first step.<\/li>- Move to
p=reject<\/code>,<\/strong> confirming DKIM is aligned on every stream first, then tighten SPF to -all<\/code>.<\/li><\/ol>\n\n\n\nStep six is the one people compress, and it is the only step that generates the information the last two depend on. Skipping it means going to enforcement blind and finding out which stream you broke from a colleague rather than from a report.<\/p>\n\n\n\n
Steps one and six are also the two that never finish. Keep the sender inventory current as vendors come and go, and keep reading reports after you reach enforcement, because a new tool bought by a department you never talk to shows up in a report long before it shows up in a conversation.<\/p>\n\n\n\n
Troubleshooting, in the order worth checking<\/h2>\n\n\n\n
When something is wrong, the first question is which of the two jobs failed. Inbound problems and spoofing problems share no diagnostic steps.<\/p>\n\n\n\n
Inbound mail is not arriving<\/h3>\n\n\n\n- Confirm the MX records exist and resolve, and that each target has an A or AAAA record.<\/li>
- Query your authoritative nameservers directly rather than a resolver, so you are looking at what you published rather than what is cached.<\/li>
- Confirm the mail host actually answers on port 25 and offers STARTTLS.<\/li>
- If all three pass, the problem is inside the mail platform: routing rules, a filter, an aliasing mistake, a mailbox over quota. It is no longer DNS.<\/li><\/ol>\n\n\n\n
dig +short NS example.com\ndig @ns1.example-dns.net example.com MX\nopenssl s_client -starttls smtp -connect mail.example.com:25<\/code><\/pre>\n\n\n\nLegitimate mail is being rejected or quarantined<\/h3>\n\n\n\n- Read the SMTP rejection text. Receivers name the reason, and DMARC-related rejections usually say so in plain words.<\/li>
- Open the headers of a message that failed and read the authentication results. They tell you which check failed and which domain was evaluated.<\/li>
- Compare the
d=<\/code> value in the DKIM signature against the From domain. If they differ and share no organizational domain, alignment is your problem.<\/li>- Count your SPF lookups. A permanent error there presents as a plain SPF failure with nothing in the record that looks wrong.<\/li>
- Check the sending IP has a valid reverse DNS record that resolves forward again. Only whoever controls the IP can set this, which means your provider if you are on shared infrastructure, or you if you run your own server.<\/li><\/ol>\n\n\n\n
dig -x 203.0.113.10 +short<\/code><\/pre>\n\n\n\nThat reverse DNS point matters more than it looks. Major mailbox providers expect sending IPs to have valid forward and reverse DNS, so if you run your own mail server, PTR control is a hard requirement rather than a nice-to-have. Confirm it before you buy. Hosts aimed at self-hosting, InterServer and Contabo among them, expose PTR in the panel; plenty of budget instances do not, and some block port 25 outright.<\/p>\n\n\n\n
Common mistakes<\/h2>\n\n\n\n- Treating
p=none<\/code> as done.<\/strong> It is a monitoring mode. It provides no protection whatsoever, and every checker will still show you a green tick.<\/li>- Publishing two SPF records.<\/strong> Usually one from the mailbox provider’s setup wizard and one from a marketing tool. The result is worse than either alone.<\/li>
- Assuming a passing DKIM signature is your DKIM signature.<\/strong> Check
d=<\/code>, not the presence of a signature.<\/li>- Editing a DKIM key in place<\/strong> instead of rotating through a second selector.<\/li>
- Leaving parked and brand domains bare.<\/strong> No MX, no SPF, no DMARC is an open invitation, and these domains are usually the ones nobody is monitoring.<\/li>
- Going to
p=reject<\/code> without DKIM aligned<\/strong> on every stream. Forwarded mail will break, and forwarded mail is disproportionately mail from customers.<\/li>- Setting
rua<\/code> and never reading it.<\/strong> Reports you do not process are the same as reports you never requested.<\/li><\/ul>\n\n\n\n
\n\n\n\nFrequently asked questions<\/h2>\n\n\n\nDo I need both SPF and DKIM, or is one enough?<\/h3>\n\n\n\n
DMARC only needs one of them to pass and align. Publish both anyway. They fail in different circumstances, and having only one means any situation that breaks it breaks all your authentication at once. Major mailbox providers also expect both from higher-volume senders, and DKIM specifically is required if you intend to publish a reject policy.<\/p>\n\n\n\n
How long should I stay at p=none?<\/h3>\n\n\n\n
Long enough to see a full cycle of your sending patterns, plus time to fix what the reports reveal. For a small business with a mailbox provider and two SaaS tools, a few weeks. For an organization with quarterly billing runs and departments who buy their own software, months. The signal to move is that you recognize every remaining failure as illegitimate, not that a calendar reminder fired.<\/p>\n\n\n\n
Will DMARC stop phishing?<\/h3>\n\n\n\n
It stops exact-domain spoofing, one technique among several. It does nothing about lookalike domains, nothing about display-name spoofing where the visible name says your CEO but the address is free webmail, and nothing about a compromised mailbox sending properly authenticated mail. One control worth having, not a phishing solution.<\/p>\n\n\n\n
Does any of this affect whether I receive email?<\/h3>\n\n\n\n
No. SPF, DKIM and DMARC describe mail leaving your domain. Only MX affects mail arriving at it. The one indirect connection is that your own inbound filtering may evaluate other people’s SPF and DKIM when deciding what to do with their mail, but that is your mail platform’s behavior, not your DNS records.<\/p>\n\n\n\n
Do I need to update my records for the new DMARC RFCs?<\/h3>\n\n\n\n
Nothing breaks if you do nothing. At your next edit, drop pct<\/code>, rf<\/code> and ri<\/code> if they are present, consider adding np<\/code> to close the non-existent subdomain gap, and if you run a deep subdomain hierarchy, publish explicit records rather than relying on inheritance. Leave the rest at defaults, because the defaults are sensible.<\/p>\n\n\n\nMy mail goes to spam even though everything passes. What now?<\/h3>\n\n\n\n
Authentication and reputation are different problems. Passing DMARC tells a receiver the mail genuinely came from you; it says nothing about whether recipients want it. If authentication is clean, look at complaint rates, list hygiene, volume ramps and content. Google publishes a spam complaint ceiling and its guidance is to operate well below that ceiling, not near it.<\/p>\n\n\n\n
\n\n\n\nWrapping up<\/h2>\n\n\n\n
If you take one thing from this, take the distinction between publishing and enforcing. Business email DNS gives you four records that answer four different questions, and only one of them, the DMARC policy tag, actually instructs a receiving server to do anything. Every free checker will confirm the records exist. None of them will tell you the dial is at zero.<\/p>\n\n\n\n
Get MX right so mail arrives. Keep SPF inside its lookup budget. Make DKIM sign with your own domain so d=<\/code> aligns. Publish DMARC at p=none<\/code> with a reporting address, read what comes back for as long as it takes, then move the dial until it reaches reject.<\/p>\n\n\n\nAnd while you are in the zone, spend five minutes on the domains nobody thinks about. A null MX, an empty SPF record and a reject policy on a parked domain is the cheapest security work available to you.<\/p>\n\n\n\n
Need a second pair of eyes on your mail domain?<\/h2>\n\n\n\n
Mail DNS is unusually well suited to outside help, because the failure is almost always somewhere the domain owner cannot see it: in a header, in a report nobody parses, or in a vendor’s include chain. Things I regularly help with:<\/p>\n\n\n\n
- Auditing an existing zone across MX, SPF, DKIM and DMARC and telling you plainly what is exposed and what is fine<\/li>
- Getting an SPF record back under the ten-lookup limit without breaking a sender you forgot about<\/li>
- Planning and executing the move from
p=none<\/code> to p=quarantine<\/code> to p=reject<\/code>, including the sender inventory and the report reading<\/li>- Setting up DMARC aggregate report collection and parsing, either self-hosted or on a processor<\/li>
- Splitting sending streams onto subdomains and migrating each one without a delivery gap<\/li>
- Locking down parked and brand-protection domains so they stop being usable in your name<\/li><\/ul>\n\n\n\n
If you would rather not describe the problem in the abstract, send me the output of a dig<\/code> against your domain, or a set of headers from a message that failed, and I will tell you what I see in it.<\/p>\n\n\n\n