In this post:
DNS authentication is the set of records you publish in your domain's DNS so that receiving mail servers can check that an email sent in your name really came from you and wasn't altered on the way. In practice it means three records working as a team, SPF, DKIM and DMARC, with a few neighbors (MX, reverse DNS and BIMI) that touch the same question.
There's no single switch called DNS authentication. Each record answers its own question, and a receiver only trusts the result when those answers point at the domain in the From line your recipient actually sees. That last condition, called alignment, is where most setups fall over. Every record looks fine in isolation, and DMARC still reports a failure.
The failures make no noise, either. A billing tool connected last spring without a DKIM key keeps sending, receivers keep filtering its mail, and the first sign anyone notices is a customer asking why their invoice went to spam.
TL;DR
SPF lists the servers allowed to send for your domain, DKIM signs each message with a key published in your DNS, and DMARC checks that at least one of them passed for the domain in the visible From address, then tells receivers what to do when neither did.
Alignment is the whole game. A tool that passes SPF and DKIM under its own domain gives your domain nothing, and DMARC fails the message.
DMARC began as RFC 7489, an informational document from 2015. The IETF's revision is now RFC 9989, a Proposed Standard dated May 2026, which drops the old pct tag for a simple test flag.
Set the records up in a fixed order: inventory your senders, MX, SPF, DKIM for every tool, a test message, DMARC at p=none with reports, then quarantine and reject. Google suggests at least a week at none before tightening. BIMI comes last because it needs enforcement.
Every cold outreach domain needs its own complete set before warmup begins, and DMARC on your main domain does nothing against lookalike domains.
The common faults are silent: a tool missing from SPF, DKIM on some platforms only, DMARC parked at none for years, and passes under the wrong domain. Aggregate reports are where they show up.
A pass proves who sent the mail. Whether it reaches the inbox still depends on reputation, the list and how recipients respond.
What DNS authentication covers, record by record
Six kinds of DNS record come up when people talk about authenticating email. Three do the authenticating, and three sit around them.
SPF. A TXT record listing the servers and services allowed to send for your domain. It's checked against the hidden return address used for bounces, not the From line. The SPF entry covers the syntax and the 10-lookup limit.
DKIM. A public key in your DNS that lets receivers verify a signature your sending platform adds to each message. Each tool gets its own key under its own selector, and the DKIM entry covers keys, selectors and rotation.
DMARC. A TXT record at _dmarc.yourdomain that ties SPF and DKIM to the visible From domain, sets a policy for failures and asks receivers to send you reports. DMARC is the record that turns the other two into protection.
MX. Says where mail for your domain should be delivered. It authenticates nothing, but a sending domain without one can't receive replies or bounce messages, and list tools use it for MX validation of the addresses you mail.
PTR, or reverse DNS. Maps a sending server's IP address back to a hostname. Google's sender guidelines require valid forward and reverse DNS for sending IPs. If you send through Google Workspace or Microsoft 365, those IPs and their PTR records belong to the platform.
BIMI. An optional record that lets supporting mail apps show your logo next to authenticated mail. It only works once DMARC is at enforcement.
Why did email need authentication added later?
The protocol that moves mail between servers lets the sender write any address into the From field, and for decades nothing checked it. That's the gap phishing and spoofing grew out of: a message could look exactly like it came from your bank or your finance director, and the receiving server had no test to run.
Each record closed part of that gap. SPF let a domain name its senders, DKIM let it sign its messages, and DMARC finally connected both to the address a person reads. Mail that passes is very likely genuine, and mail that fails can be treated with suspicion instead of guesswork, which is exactly the split providers wanted before they started enforcing it.
How SPF, DKIM and DMARC hand a message along
The easiest way to see how the three fit together is to follow one message from a Dutch company, yourcompany.nl, through three situations.
Mail from Google Workspace. Anna sends from anna@yourcompany.nl. The return path is on yourcompany.nl, so SPF passes for yourcompany.nl. Google signs with d=yourcompany.nl, so DKIM passes for the same domain. Both line up with the From address, and DMARC passes.
Mail from a webinar tool nobody connected properly. The tool sends invitations as anna@yourcompany.nl, but its return path sits on the tool's own bounce domain and it signs with d=webinartool.example. SPF passes, for the tool's domain. DKIM passes, for the tool's domain. Neither matches yourcompany.nl, so DMARC fails, and under a reject policy the invitation never arrives.
The same tool after the fix. Someone publishes the tool's DKIM key under yourcompany.nl, and it now signs with d=yourcompany.nl. SPF still passes only for the tool's domain, but DMARC needs just one aligned pass, so the message passes.
Alignment comes in two strengths. Relaxed, the default, accepts a subdomain, so a signature from mail.yourcompany.nl counts for yourcompany.nl. Strict wants an exact match. Most domains are fine on relaxed.
The second situation is the one we find most often. The fix nearly always sits in the tool's settings, where there's a page for adding its records to your DNS that nobody opened. An aligned DKIM signature is worth getting even when SPF already aligns, because SPF breaks when mail is forwarded and a signature inside the message usually survives.
DMARC policies, reports and the 2026 standard
A DMARC record carries a policy and a reporting address. The policy, set with the p tag, has three values. With none, the domain owner expresses no preference and receivers handle failures as they normally would. With quarantine, failing mail is treated as suspicious, which usually means the spam folder. With reject, failing mail is refused outright.
The rua tag tells receivers where to send aggregate reports. These are daily summaries from each provider that reports, listing the IP addresses that sent mail as your domain, how many messages each sent and whether they passed SPF, DKIM and alignment. They're XML and unpleasant to read raw, so most teams run them through a report viewer. They're also the only place you'll see every service sending in your name.
The standard itself has just changed. DMARC was first published in March 2015 as RFC 7489, an informational document from the Independent Submission stream rather than an IETF standard. The IETF's revision, known as DMARCbis, is listed on the IETF datatracker as RFC 9989, a Proposed Standard dated May 2026, which obsoletes RFC 7489.
For most domain owners the record looks the same as before. The visible change is the pct tag, which let you apply a policy to a percentage of failing mail. RFC 9989 notes that receivers rarely applied it accurately unless the value was 0 or 100, and replaces it with a t tag that simply switches test mode on or off.
The order to set up DNS authentication on a new domain
Each record leans on the ones before it, so the order matters more than the speed. This is the sequence we follow for any domain that will send mail:
List every sender. The mailbox platform, CRM, marketing tool, help desk, billing system, webinar tool and any cold email tool. Missing one here is the source of most later failures.
Publish MX if the domain should receive mail, which every domain that sends cold email should, since replies and bounces need somewhere to go.
Publish one SPF record that names every sender, and count its DNS lookups before you publish.
Switch on DKIM in every tool and publish each key under its own selector, so each one signs as your domain.
Send a test to a mailbox at a different provider (a private Gmail account works) and view its raw headers. The Authentication-Results header should show spf=pass and dkim=pass, with your own domain next to each.
Add DMARC at p=none with a rua address. Google's recommended DMARC rollout says to set up SPF and DKIM at least 48 hours first, start at none for one week and review the reports daily.
Tighten to quarantine, then reject, once the reports show every legitimate source passing and aligned. Google's guide still describes raising quarantine by percentage, so if you follow it, remember that the pct tag no longer exists in the new standard.
Add BIMI if you want it. Google's BIMI setup page requires a DMARC policy of quarantine or reject at 100%, a Verified Mark Certificate or Common Mark Certificate from a third-party certificate authority, and an SVG logo.
A simple domain with one or two senders can reach reject within a few weeks. A company domain with a decade of tools behind it takes longer, because the reports keep turning up senders nobody remembered.
What changes for cold outreach domains
Each secondary domain used for cold email infrastructure is a domain in its own right. It needs its own SPF, its own DKIM key in the sending platform, its own DMARC record and an MX record, all published and tested before warmup starts. Warming a domain that fails its checks means weeks of history built on mail receivers couldn't attribute to you.
Since February 2024, Gmail and Yahoo have required SPF, DKIM and DMARC from bulk senders, and the rest of their rules are covered under email deliverability. Cold domains sit well below the bulk line, but a domain with no history has nothing else to vouch for it, so receivers lean harder on the records.
Cold domains also have an advantage: they usually send from one mailbox platform and one sending tool, so there are only two sources to align. That makes them easy to take to enforcement quickly once the first reports come back clean.
One limit is worth knowing. DMARC at reject on yourcompany.nl stops anyone sending as exactly yourcompany.nl. It does nothing about yourcompany-mail.nl or any other lookalike, which is precisely what cold sending domains are. Keep a list of every lookalike you own, point each one's website at your main site, and give domains you own but never send from an SPF record of v=spf1 -all and a DMARC policy of reject, so nobody can borrow them.
Where a setup that looks finished still leaks
A broken record never throws an error in your sending tool. These are the faults that keep turning up in audits, usually several at once:
A sender missing from SPF. One tool's mail fails while everything else passes, so the blended numbers barely move.
DKIM on some platforms but not all. Every tool added later opens a new gap until someone publishes its key.
DMARC left at p=none indefinitely. You collect reports and get no protection. We regularly find domains that have sat at none for years because nobody owned the next step.
Passes under the wrong domain. SPF and DKIM both pass, for a vendor's domain, so DMARC fails. This is the webinar tool from earlier.
An SPF record over its lookup limit. Ten DNS lookups is the ceiling, and nested includes count, so a record can break for every message when a vendor changes its own record.
Part of the reason these linger is that DNS usually sits with IT while the deliverability pain sits with sales and marketing, so nobody owns the list of senders. Making a new tool's DNS records part of switching it on closes most of the gap.
After enforcement, read the aggregate reports at least monthly and after every change to the stack, and include authentication in each outbound deliverability audit. A source that suddenly starts failing is either a tool someone added without telling you or someone sending as you who shouldn't be. Either way, the report is where you'll see it first.
What does passing DNS authentication actually buy you?
It settles identity, and only identity. Once a receiver knows the mail is really from yourcompany.nl, it judges that domain on its record: complaints, bounces, engagement and how steadily it sends. That's domain reputation and the wider sender reputation, and authentication is what lets a provider attach that history to you in the first place.
So a fully authenticated domain that mails a scraped list still lands in spam, and we've watched it happen for months at a time. The records protect your inbox placement rate without deciding it. They also protect something placement numbers don't show: without DMARC at enforcement, anyone can send phishing as your exact domain, and recipients will blame your brand for it.
The bottom line
DNS authentication answers the first question every receiving server asks: is this mail really from who it says? SPF, DKIM and DMARC each answer part of it, and the answer only counts when it points at the domain in the From line. Get alignment right and the rest is upkeep.
The setup itself is a few days of work spread over a few weeks, mostly spent waiting for reports. The upkeep is where teams slip: every new tool needs its records, every report needs a glance, and somebody has to own the list of who sends as you. Without that owner, a correct setup drifts back into a leaky one within a year.
When Nebor sets up a client's sending infrastructure, the records go into the client's DNS for the main domain and every sending domain, with a short register of each sender, its selector and its DMARC status. That register stays with the client, so whoever adds the next tool can see what's already there and what it needs.
Frequently asked questions
How is DNS authentication different from encryption like TLS?
They do separate jobs. TLS encrypts the connection between two mail servers so nobody can read the message while it travels. DNS authentication hides nothing. It proves which domain sent the message and that the signed parts weren't changed. Google's sender guidelines ask for both, a TLS connection for transmitting mail and SPF, DKIM and DMARC for identity, and neither one replaces the other.
IT controls our DNS but sales feels the deliverability pain. Who should manage the records?
Split it deliberately. One person, often in RevOps or marketing operations, owns the list of every tool that sends as the company and decides what each one needs. IT publishes and maintains the records in DNS. Make adding a tool's SPF and DKIM records part of switching that tool on, and have both sides look at the DMARC reports together once a month.
How long after publishing do SPF, DKIM and DMARC start working?
Usually within hours, but allow up to two days. Google says SPF can take up to 48 hours to start working, and its DMARC rollout guide asks you to set up SPF and DKIM at least 48 hours before adding DMARC. After publishing, send a test message to an outside inbox and read the Authentication-Results header rather than trusting the green tick in an admin console.
Do subdomains need their own SPF, DKIM and DMARC records?
For SPF, yes. Google and Microsoft both say every subdomain that sends mail needs its own SPF record, because the parent's record doesn't cover it. DKIM keys are set per signing domain in each tool. DMARC works differently: Microsoft notes that subdomains inherit the parent domain's DMARC settings unless you override them, so one policy on the main domain also covers subdomains nobody has set up.
What is BIMI, and is it worth setting up?
BIMI lets supporting mail apps show your logo next to messages that pass DMARC. Google requires a DMARC policy of quarantine or reject applied to all mail, a Verified Mark Certificate or Common Mark Certificate from a third-party authority, and an SVG logo. It's worth doing for brands sending lots of customer email. For cold outreach domains it adds cost without changing placement.
Does reverse DNS matter if you send through Google Workspace or Microsoft 365?
Not as a task for you. Google's sender guidelines require that sending IP addresses have valid forward and reverse DNS, meaning a PTR record that resolves to a hostname matching the IP. When your mail leaves through Google's or Microsoft's servers, those IPs and their PTR records belong to the platform. Reverse DNS becomes your job only if you run your own mail server.
What is the difference between p=quarantine and p=reject?
Both are enforcement policies for mail that fails DMARC. Quarantine asks receivers to treat failing mail as suspicious, which in practice usually means the spam folder. Reject asks them to refuse it during delivery, so it never reaches the recipient at all. Most domains pass through quarantine first, watch the reports for legitimate mail getting caught, and move to reject once nothing is.
Can a strict DMARC policy block mail from our own tools?
Yes, and that's the main risk of moving too fast. If a tool sends as your domain without an aligned SPF or DKIM pass, a reject policy tells receivers to refuse its mail, whether that's invoices, password resets or webinar invitations. Read the aggregate reports first, fix every legitimate source that fails, and only then tighten the policy.
How can you check a message's authentication results in Gmail?
Open the message, choose Show original from the menu, and Gmail shows a summary with SPF, DKIM and DMARC each marked as pass or fail. Look further down at the Authentication-Results header for the domain each check passed for. A DKIM pass for a vendor's domain instead of yours means the tool isn't signing as you, even though the word pass is there.
Share this post
Deliverability
Infrastructure
Glossary
Related glossary items
Understanding the core GTM concepts
Ready to build your pipeline
