SPF, DKIM and DMARC are three DNS records that let receiving mail servers tell your company’s messages apart from forgeries. SPF lists the servers allowed to send mail for your domain, DKIM adds a cryptographic signature to every message, and DMARC tells the receiver what to do with mail that passes neither check. All three are needed, and in exactly that order.
Key takeaways
The “From” field is filled in by the sending server, and the SMTP protocol never verifies it. Anyone can send a message that shows your accounting team’s address — the only question is whether the receiving server believes it. These three records are the answer to that question.
Behind those numbers sit simple schemes: a partner receives an invoice with someone else’s bank details, an employee gets a message “from the director” asking for an urgent payment. Authentication records do not make correspondence invincible, but they take away the attacker’s most convenient tool — your own domain.
SPF, DKIM and DMARC are three independent checks a receiving server runs the moment a message arrives. Each answers a different question, and none of them protects the domain on its own.
The key concept in DMARC is alignment: the domain in the visible “From” field has to match the domain that SPF validated or DKIM signed. In relaxed mode the organisational domains match; in strict mode the full names must be identical. Without alignment SPF can pass while DMARC still fails — and that is exactly how mail sent from a foreign server under your name gets stopped.
Important DMARC without SPF and DKIM is pointless: it has nothing to evaluate. Publish the first two records first, and only then the third.
SPF is a single TXT record at the root of the domain, and you cannot add a second one: with two records the check becomes invalid. The work starts not in DNS but with a list of every service that sends mail on your behalf.
The real constraint in SPF is not record length but the number of DNS lookups. RFC 7208 allows no more than ten lookups for the whole evaluation, nested includes counted, and requires a permerror result once that limit is exceeded. For DMARC that is the same as a failed check. The same document advises capping “void” lookups — those that return no records — at two.
Mistake Adding one more include “just in case” and crossing the ten-lookup line. The record still looks correct, yet not a single message passes. Drop the unused includes and replace heavy ones with explicit addresses.
DKIM is enabled in the mail provider’s console: it generates a key pair and hands you a ready TXT record for DNS. The record name combines a selector with the _domainkey suffix — google._domainkey for Google Workspace, for example.
In one common case DKIM matters more than SPF — forwarding. When a recipient automatically forwards a message elsewhere, the sending server changes and SPF breaks, while the signature stays valid. So lean on DKIM and keep SPF as the second mechanism.
DMARC is a single TXT record under the name _dmarc.yourdomain. A minimal working version holds a version, a policy and a reporting address. Google’s instructions advise waiting 48 hours after SPF and DKIM are in place and starting with the none policy.
Aggregate reports are the main reason to turn DMARC on even in none mode. They reveal every server sending mail under your domain: your own services, a forgotten old website, and third-party servers pushing forgeries. Reading XML by hand is awkward, so reports go to an analytics service or to a separate mailbox with automated parsing.
The move is gradual: first you find every legitimate sender in the reports, then you tighten the policy. A sudden reject on an unverified domain bounces your own invoices and notifications.
Tip Do not change the policy during a period when mail is critical: before a reporting deadline, during a tender or a sale. An alignment error under reject is noticed by your counterparty, not by your own staff.
Gmail has applied authentication requirements to all senders since 1 February 2024, and Outlook.com since 5 May 2025. For large senders both services ask not for one record but for all three.
| Requirement | Gmail | Outlook.com |
|---|---|---|
| In force since | 1 February 2024 | 5 May 2025 |
| Bulk sending threshold | more than 5,000 messages a day | more than 5,000 messages a day |
| For all senders | SPF or DKIM, valid forward and reverse DNS records, TLS in transit | requirements are set for senders above the threshold |
| For bulk senders | SPF and DKIM together, DMARC at least none, an aligned “From” domain, one-click unsubscribe | SPF and DKIM must pass, DMARC at least none with alignment |
| If the requirements are unmet | mail lands in spam more often and may not arrive at all | mail goes to the junk folder and will later be rejected |
The requirements are published in Google’s guidelines for senders and in the Outlook.com policy for mail administrators. Gmail watches one more threshold separately: the spam complaint rate in Postmaster Tools has to stay below 0.3% (Google Email Sender Guidelines).
The practical conclusion for a company is this: without the three records you lose not only protection against forgery but the deliverability of ordinary working mail — invitations, invoices, replies to enquiries. To a filter, an unauthenticated domain looks much like a fraudster’s.
Most authentication problems come not from hard cases but from simple missed steps. Run through this list before enabling a strict policy, and repeat it every time a new sending service appears.
The three records close off address forgery, but not channel encryption or message recognisability. Two steps follow. MTA-STS (RFC 8461) publishes a policy requiring other servers to deliver mail to you only over verified TLS and, in enforce mode, to refuse delivery when TLS is unavailable. BIMI shows your company logo in the message list, and under the BIMI Group requirements the DMARC policy for it must be quarantine or reject: the logo is granted only to a domain with an enforcing policy.
The technical requirements are the same in any country, but the order of work depends on who holds the domain’s DNS. For a domain in the uz zone the records are edited in an accredited registrar’s console or at the provider the name servers are delegated to, and access often stayed with the contractor who built the website. Step one is getting that access back.
At Syntra Systems email protection is part of our cybersecurity work. We start with an inventory of senders: it often turns out that more mail leaves under the domain than accounting knows about — old website forms, a forgotten campaign tool, a test server. Then we build SPF with headroom on the lookup limit, enable DKIM for every sender, and walk the domain from none to reject guided by reports rather than guesswork.
These records are part of the wider picture we lay out when we design protection: there is more on that in our article on security at the design stage. An information security audit, which covers mail as well, starts at $1,200; building out data and access protection starts at $4,000; security event monitoring starts at $800 a month. The full scope is on our cybersecurity page.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
The move is measured in weeks: reports in none mode are collected for two or three weeks so that rare senders such as monthly statements show up, then quarantine goes on with partial coverage, and only after that comes reject. Rushing does not pay — an error under an enforcing policy is spotted by your counterparty, not by your own staff.
Remove unused includes and replace heavy ones with explicit addresses: the limit counts DNS lookups, not record length. Bulk campaigns are better moved to a dedicated subdomain, which gets its own SPF record and its own headroom.
Yes, and in that case they matter even more. A domain without DMARC is a convenient platform for forgery: the attacker does not need your server, only your name in the “From” field. For a domain that sends no mail at all, publish an empty SPF record and a DMARC refusal.
Most likely alignment is broken: SPF validated the sending vendor’s domain while the visible “From” field shows yours. DMARC treats such a message as unauthenticated. The fix is a DKIM signature with your domain, or sending from an address on your own domain.
The owner of the domain’s DNS is usually a system administrator or an IT contractor, but the company itself must also hold access to the registrar console. DMARC reports need regular reading: every new campaign tool changes the picture of senders.
No. The records protect your domain only, and a message from a similar address passes its own checks without fault. What counters this is staff training, a rule to confirm bank details by phone, and registering lookalike domains yourself.
At Syntra Systems this is part of our cybersecurity work: an information security audit that covers mail as well starts at $1,200, building out data and access protection starts at $4,000, and security event monitoring starts at $800 a month.
Sources
Cover photo: Feyza Yıldırım, Pexels
