Activity

The complaints arrive in a predictable order. DNS lookup tool says they never got the invoice. Then a sales rep notices replies have dried up. Then someone forwards a screenshot of your password reset email sitting in a junk folder next to a cryptocurrency pitch. By the time anyone treats this as a technical problem rather than bad luck, the delivery reputation has usually been degrading for months. Almost always, the cause is not the content of the messages. It is three DNS records that were configured once, incompletely, by someone who has since left, and never checked again.

The three records, and what each one actually proves

SPF, DKIM, and DMARC are often described as a bundle, which obscures that they answer three different questions. SPF publishes a list of servers permitted to send mail for your domain, so a receiving server can ask whether this message came from an approved address. DKIM attaches a cryptographic signature to the message itself, letting the receiver verify the content was not altered in transit and that it was signed by someone holding your private key. DMARC ties the other two to the domain your recipient actually sees in the From field and tells receivers what to do when the check fails. You need all three because each covers the others’ gaps: SPF breaks when mail is forwarded, DKIM survives forwarding but says nothing about which servers may send, and neither one alone stops somebody from signing their own mail and putting your brand in the From line.

The ten lookup limit is why your SPF record silently stopped working

SPF has a hard cap: evaluating your record may trigger no more than ten DNS lookups, and every include, a, mx, ptr, and exists mechanism counts. Exceed it and the result is not a partial pass. It is a permanent error, which many receivers treat as a failure, and your legitimate mail starts getting penalised. This limit is the single most common SPF fault in the wild, and it happens through entirely ordinary growth: your mail host is one include, your marketing platform another, then a helpdesk, an invoicing tool, a CRM, an event platform, a survey vendor somebody trialled in 2022. Several of those includes expand into further includes you cannot see, so a record that looks like five entries can consume fourteen lookups. Count them properly with a validator rather than by eye, remove services you no longer use, and if you are still over the limit, flatten the record or consolidate senders.

Softfail, hardfail, and the choice most people get wrong by default

The end of your SPF record says either ~all or -all, and the difference matters more than its subtlety suggests. Softfail (~all) tells receivers that mail from unlisted servers is probably not legitimate but asks them to accept it anyway, usually with a reputation penalty. Hardfail (-all) tells them to reject it. Most domains sit on softfail because that is the default their provider generated, and it is the correct place to start, but staying there indefinitely means you have published a rule you are not willing to enforce. The path is to reach genuine confidence that your record lists every sending source, verify that with a week of DMARC reports, and then tighten. What you must not do is publish -all while a forgotten department still sends invoices through a tool that is not in the record, because you will have configured your own outage.

DKIM fails quietly, and usually because of the selector

DKIM problems are harder to spot than SPF problems because nothing looks wrong from your side. The message leaves, the signature is attached, and the receiver cannot validate it. The usual reasons are mundane: the public key was never published at the selector the sending platform is using, the record was truncated when it was pasted into a DNS panel that has a character limit per string, the key was rotated on the platform but not in DNS, or a provider is signing with a 1024-bit key that some receivers now treat with suspicion. Each sending source needs its own selector and its own published key, which means adding a new email vendor is a DNS task, not just an account setup. Check the actual signature on a received message rather than trusting the vendor’s green tick, because the vendor is confirming it signed, not that anyone verified.

Alignment is the concept that makes DMARC work, and it is not obvious

Here is the part that trips up people who have configured all three records and still see failures. DMARC does not merely require that SPF or DKIM pass. It requires that one of them pass and that the domain it authenticated match the domain in the visible From header. This is alignment, and it is why mail sent through a third-party platform frequently fails DMARC despite passing SPF: the platform’s envelope sender is its own domain, SPF validates against that, and the alignment check fails because your customer sees your domain in the From field. The fix is to configure a custom return path or a properly delegated sending subdomain with the vendor, and to ensure DKIM signs with your domain rather than theirs. Any vendor that cannot support DKIM signing on your own domain should be treated as a liability.

Read your DMARC reports before you enforce anything

The policy field has three values. p=none means monitor only, p=quarantine means route failures to spam, p=reject means refuse them outright. Almost every domain that has DMARC at all is sitting on p=none with no reporting address configured, which means it has all of the appearance of protection and none of the substance. Add an rua address, wait a week, and read what arrives. The aggregate reports are XML and unpleasant to read raw, so use a parser, but the picture they give you is the only reliable inventory of who sends mail as your domain — including the services you forgot, the ones a department signed up for on a card you do not see, and any actual spoofing. Only after that inventory is complete and every legitimate source authenticates cleanly should you move to quarantine, then to reject. Rushing to reject blocks your own transactional mail, and transactional mail is the kind whose failure costs money.

Do not forget the subdomains, or the domains you never send from

Two gaps that attackers know about and administrators forget. First, DMARC has a separate subdomain policy tag, sp=, and if you do not set it, subdomains inherit the organisational policy — which is useful when your main policy is strict, and useless when it is not. Spoofing a subdomain nobody has ever used for mail is a standard technique precisely because the protections are usually thinner there. Second, if you own parked domains, old brand variants, or typo defences that never send mail at all, publish an SPF record of v=spf1 -all, a DMARC record of p=reject, and a null MX record on each one. It takes two minutes per domain and it removes them as forgeable assets. Attackers look for the domain you are not watching.

The bulk sender rules changed the stakes, and they now apply to Outlook too

For years this was a best-practice conversation. It is now a requirement. Google and Yahoo introduced enforced authentication standards for bulk senders in February 2024, and Microsoft followed with equivalent requirements for high-volume senders to Outlook and Hotmail addresses. The shared shape of the rules is consistent: SPF and DKIM both configured, a DMARC record present with at least p=none, alignment between the authenticated and visible domains, valid forward and reverse DNS on your sending servers, functioning one-click unsubscribe on marketing mail, and spam complaint rates kept well below a stated threshold. The volume triggers and exact thresholds differ by provider and have been revised since launch, so check each provider’s current sender guidelines directly rather than trusting a summary. The direction of travel is not in doubt: unauthenticated bulk mail is being phased out.

Check the records from outside, all at once

Every claim above is verifiable from outside your organisation, which is the right vantage point because your DNS panel shows you what you intended rather than what resolves. Running the domain through a website health checker returns the SPF, DKIM, and DMARC status alongside the DNS records, MX configuration, certificate details, and response headers, so you see the mail setup in the context of everything else rather than as an isolated puzzle. That context matters more than it sounds: mail problems on established domains are usually entangled with the rest of the infrastructure, and the record you cannot explain is frequently a leftover from a migration that also left stale CNAMEs and a certificate covering the wrong hostnames.

Reputation is behavioural, and no DNS record will save you from bad sending habits

Authentication proves you are who you claim to be. It does not prove anyone wants your mail, and receivers judge that separately by watching behaviour. Complaint rates, hard bounces to addresses that never existed, sudden volume spikes from a domain with no sending history, and engagement rates all feed reputation scores that no TXT record can override. The practical consequences are specific: never buy lists, honour unsubscribes immediately and completely, remove hard bounces after a single failure, warm new sending domains and IPs gradually over weeks rather than blasting on day one, and separate your transactional mail from your marketing mail onto different subdomains so a bad campaign cannot poison your password resets. That last one is the highest-value structural decision in the whole area.

The extras worth knowing about, in order of usefulness

Once the fundamentals are enforcing, a few additions are worth the effort. MTA-STS and TLS-RPT tell sending servers to require encrypted delivery to your domain and report when it fails, which closes a downgrade attack that authentication does not touch. ARC helps preserve authentication results through legitimate forwarding, such as mailing lists, and is largely handled by your provider rather than by you. BIMI displays your verified logo next to your messages in supporting clients, but it requires DMARC at quarantine or reject and a paid Verified Mark Certificate, so it is a reward for finishing the work rather than a step in it. Ignore anyone who suggests BIMI before your DMARC policy is enforcing, because it is not technically possible and the suggestion tells you how carefully they read.

Make it somebody’s recurring job

The reason this breaks is not that it is difficult. It is that it is invisible until it fails, and nothing in a normal workflow prompts anyone to check. So build the prompt. Put the DMARC reports in front of a named person weekly, review the SPF record whenever any team signs up for a tool that sends mail, rotate DKIM keys on a schedule and verify the new key resolves before decommissioning the old one, and re-audit the whole configuration quarterly. Add one line to your vendor onboarding checklist: does this service send email as us, and if so, who is publishing the DNS records. That single question prevents most of what this article describes.

If you only have twenty minutes

Look up your DMARC record and check whether it exists, what its policy is, and whether it has a reporting address. If there is no rua tag, add one now, because you cannot fix what you cannot see. Count the DNS lookups in your SPF record with a validator and confirm you are under ten. Send a message to an address at a major provider, open the raw headers, and confirm SPF, DKIM, and DMARC all show pass with your own domain in the aligned position. Then list every service that sends mail on your behalf and check each one has a published DKIM selector. That is the twenty-minute version, and it will tell you whether your next problem is a small configuration fix or a months-long reputation recovery.