Email Authentication: Configure SPF, DKIM, and DMARC Correctly

8 Min. Read

Your company’s emails have been landing in customers’ spam folders for weeks. The IT admin has checked everything, the mail server is running clean, but Google keeps filtering them out. The reason is almost always the same: missing or misconfigured email authentication. Since February 2024, Google and Yahoo have required DMARC for all bulk senders. Since November 2025, Gmail categorically rejects non-compliant emails. Anyone who has not configured SPF, DKIM, and DMARC correctly loses not only deliverability but also turns their domain into a phishing tool for attackers.

Key Takeaways

Google and Yahoo have required DMARC for bulk senders since February 2024. Gmail has been rejecting non-compliant emails since November 2025. Microsoft followed in May 2025.
SPF adoption stands at 93 percent in 2026, DKIM at 90 percent. DMARC stagnates at 64 percent, with only 4 percent of all top domains using the strictest policy (reject).
The three protocols build on each other: SPF verifies the sending server, DKIM signs the content cryptographically, DMARC combines both with a policy and reporting.
The average cost of a phishing breach was 4.88 million US dollars in 2025. Correctly configured email authentication is the single most effective measure against domain spoofing.
Setting up all three protocols takes three to five working days for a mid-sized company, but requires careful preparation and a gradual tightening of the policy.

Three Protocols, One Goal: Who Is Allowed to Send Email in Your Name?

Email authentication answers a simple question: is the server sending this email authorized to send on behalf of this domain? Without authentication, any mail server can send emails using your sender domain. Phishing emails, fake invoices, CEO fraud instructions – all possible because the SMTP protocol has no built-in sender verification.

The three protocols SPF, DKIM, and DMARC solve this problem at different levels. They complement each other and are only truly effective in combination. A company that uses only SPF without DKIM and DMARC has done half the job and barely benefits from the investment.

SPF (Sender Policy Framework): Who Is Allowed to Send?

SPF defines in a DNS TXT record which IP addresses and servers are authorized to send emails for your domain. The receiving mail server checks with every incoming email whether the IP of the sending server is listed in the SPF record of the sender domain. If it is not, the email can be marked as suspicious or rejected. Important: SPF has a limit of a maximum of 10 DNS lookups. Companies with many third-party providers (CRM, newsletter tools, ticketing systems) quickly hit this limit. The solution is SPF flattening tools or consolidation of the sending infrastructure.

DKIM (DomainKeys Identified Mail): Has the Content Been Altered?

DKIM adds a cryptographic signature to every outgoing email. The sending server signs defined header fields and the body with a private key. The public key is published as a DNS record. The receiving server checks the signature against the public key and can thus determine whether the email was altered in transit. DKIM therefore protects not only the sender identity but also the integrity of the content. This is particularly relevant for industries with compliance requirements, where the immutability of business communications must be demonstrable.

DMARC (Domain-based Message Authentication, Reporting and Conformance): What Happens on Violations?

DMARC combines SPF and DKIM with a policy that tells the receiving server what to do with emails that fail either check. The three policy levels are: none (only observe and report), quarantine (move suspicious emails to spam), and reject (reject emails entirely). In addition, DMARC provides reporting: daily reports show who is sending emails in your name, which emails pass SPF and DKIM and which fail. These reports are invaluable for identifying shadow IT and unauthorized third-party providers.

SPF, DKIM, and DMARC Compared

Criterion	SPF	DKIM	DMARC
What is checked	IP of the sending server	Cryptographic signature	SPF + DKIM alignment
Protection against	Unauthorized servers	Content manipulation	Domain spoofing
DNS record type	TXT	TXT (CNAME with providers)	TXT
Setup effort	Low (1 DNS record)	Medium (key pair + config)	Medium to high (policy tuning)
Most common mistake	More than 10 DNS lookups	Forgetting key rotation	Jumping straight to reject instead of gradual rollout
Adoption 2026	93 %	90 %	64 % (only 4 % reject)

Why DMARC Is the Critical Building Block

SPF and DKIM alone are not enough. Without DMARC there is no policy telling the receiving server what to do when an authentication check fails. This means: even if SPF and DKIM are correctly configured, an attacker can still send emails with a spoofed sender address that passes neither SPF nor DKIM, and the receiving server decides at its own discretion what to do with them.

64 %

of email domains have a DMARC record in 2026. But only 4 percent use the strictest policy (reject). The rest are only observing.

4.88 million US dollars

average cost of a phishing breach in 2025. Email remains the primary attack vector for phishing and CEO fraud.

41 %

of banks have no DMARC protection. A dangerous gap exists particularly in regulated industries.

Sources: EasyDMARC Adoption Report 2026, IBM Cost of a Data Breach 2025, PowerDMARC Security Trends 2026

The enforcement wave from major email providers has massively increased the urgency. Google and Yahoo made DMARC mandatory for bulk senders in February 2024. Gmail went one step further in November 2025 and began rejecting non-compliant emails outright rather than just flagging them. Microsoft followed in May 2025 with Outlook.com and Microsoft 365. Anyone without a valid DMARC record risks their business emails simply not arriving anymore.

For companies in Germany there is an additional aspect: domain spoofing is a preferred tool for CEO fraud and invoice fraud. An attacker who can send emails in the name of your domain because no DMARC reject is active can reach your customers with fake invoices or payment instructions. The reputational damage from such an attack far exceeds the cost of DMARC setup. And the damage does not only affect the company itself: customers and partners who fall for the fake emails also suffer financial losses and lose trust in your brand.

The Most Common Mistakes During Setup

The protocols are not complex, but implementation has its pitfalls. The following five mistakes cause the most problems in mid-sized companies.

SPF with more than 10 DNS lookups: Every include entry in the SPF record generates DNS queries. Companies using Salesforce, HubSpot, Mailchimp, and Microsoft 365 simultaneously quickly exceed the limit of 10 lookups. The consequence: the SPF record is ignored entirely. The solution is SPF flattening, where nested lookups are resolved into direct IP ranges.

DKIM keys never rotated: DKIM keys should be changed every six to twelve months. Many companies set up DKIM once and forget to rotate. A compromised private key allows attackers to send validly signed emails in your name.

DMARC set directly to reject: Starting DMARC with the reject policy immediately risks blocking legitimate emails from third-party providers. The safe approach: start with none, analyze the reports for two to four weeks, then switch to quarantine, and move to reject after another two weeks.

Forgetting subdomains: DMARC applies by default only to the main domain. Subdomains such as mail.company.com or newsletter.company.com need either their own DMARC record or the main domain policy must set the sp= (subdomain policy) parameter. Attackers specifically target unprotected subdomains for spoofing.

Not evaluating reports: DMARC reports are sent as XML to the address stored in the record. Without a tool for evaluation they are practically unusable. Services like dmarcian, EasyDMARC, or Valimail visualize the data and show which sources are sending emails in your name. This transparency is the real value of DMARC in monitoring mode.

Checklist: Setting Up Email Authentication in 5 Days

Day 1: Inventory

Inventory all email-sending systems: mail server, CRM, newsletter tool, ticketing system, marketing automation
Check existing SPF and DKIM records: dig TXT company.com and dig TXT selector._domainkey.company.com
List all subdomains that send emails

Day 2: Configure SPF

Consolidate all authorized sender IPs and include entries into one SPF record
Check DNS lookup limit (max. 10), apply flattening if needed
Publish SPF record as DNS TXT record and run validation

Day 3: Set Up DKIM

Generate DKIM key pair for the main mail server (RSA 2048 bit or Ed25519)
Publish public key as DNS TXT record
Activate DKIM signing in the mail server and send test emails
Enable DKIM for third-party providers (most SaaS tools offer CNAME-based DKIM integration)

Day 4: Start DMARC with Monitoring

Publish DMARC record with p=none and rua address for reports
Set up reporting recipient (external address or DMARC analysis tool)
Check first reports after 24 hours: which sources pass SPF and DKIM, which do not?

Day 5 to Week 6: Tighten Gradually

Identify unauthorized sources and either legitimize or block them
After 2 weeks of stable reports: set p=quarantine
After another 2 weeks: activate p=reject
Add subdomain policy via sp= parameter
Schedule DKIM key rotation every 6 months

Conclusion: Three DNS Records That Protect Your Domain

Email authentication is no longer an optional best practice – it is mandatory. Anyone without a DMARC record with enforcement risks both deliverability problems with Google, Yahoo, and Microsoft and the misuse of their domain for phishing attacks. The setup requires no expensive software and no external consulting project. It requires care during the inventory, patience when tightening the policy gradually, and the discipline to evaluate reports regularly.

Start today with an SPF check of your main domain. Check whether a DKIM key is published. And if no DMARC record exists: set it up with p=none and a reporting address. The reports alone will show you who is sending emails in your name. The result is often surprising and almost always actionable.

A final note for companies that have already set up SPF and DKIM but are hesitating with DMARC: monitoring mode (p=none) has no effect whatsoever on the delivery of your emails. It only collects data. There is no reason to delay this step. The transparency that DMARC reports deliver is already a security gain in itself, even before the first email is blocked.

Frequently Asked Questions

What happens if I don’t set up DMARC?

Without DMARC, attackers can send emails in the name of your domain without receiving servers having a policy to block those emails. Since November 2025, Gmail rejects non-compliant bulk emails. Microsoft 365 followed in May 2025. Your business emails can end up in spam or be rejected entirely, while phishing emails using your domain pass through unimpeded.

In what order should I set up SPF, DKIM, and DMARC?

First SPF, then DKIM, then DMARC. SPF is the easiest starting point and requires only one DNS record. DKIM needs a key pair and configuration on the mail server. DMARC requires at least one of the other two protocols to be functioning, ideally both. Always start DMARC with p=none and tighten gradually.

What is the SPF limit of 10 DNS lookups?

The SPF standard allows a maximum of 10 DNS lookups per check. Every include entry in your SPF record generates at least one lookup. Companies that use many third-party services for sending email quickly exceed this limit. If the limit is exceeded, the entire SPF record is ignored, which is worse than having no SPF at all. The solution is SPF flattening or consolidation of the sending infrastructure.

How long does it take for DMARC to take effect?

The technical setup takes one day. It takes four to six weeks until the reject policy is active and safe. During this time DMARC runs in monitoring mode (p=none) and collects reports about who is sending emails in your name. This phase is critical for identifying legitimate third-party providers and avoiding accidentally blocking them.

Do I need a special tool for DMARC?

Not for the setup itself. SPF, DKIM, and DMARC are DNS records that can be set with any DNS provider. For evaluating DMARC reports, however, an analysis tool is strongly recommended. The reports arrive as XML files and are barely usable without visualization. Services like dmarcian, EasyDMARC, Valimail, or PowerDMARC offer clear dashboards from around 100 euros per year for small businesses.