Why Email Authentication Is Essential
The Simple Mail Transfer Protocol (SMTP) was developed in 1982 without built-in authentication. Any server can send an email with any sender address. This makes email spoofing trivial: an attacker can send emails that appear to come from your-company@your-domain.com. Recipients see your domain as the sender and trust the message.
The consequences are severe: phishing emails in your company's name damage customer trust. When recipients mark spoofing emails as spam, your domain's reputation with mailbox providers drops. Your legitimate emails then also land in spam. In the worst case, your domain is placed on a blacklist and none of your emails are delivered.
SPF: Which Servers May Send Emails?
The Sender Policy Framework (SPF) is the first building block of email authentication. It defines via a DNS TXT record which IP addresses and servers are authorized to send emails for your domain. The receiving server checks the sending server's IP address against the sender domain's SPF record.
Creating an SPF Record
An SPF record is a DNS TXT entry for your domain. It begins with the version identifier v=spf1, followed by mechanisms that define authorized senders. The record ends with a qualifier-all directive that determines how unauthorized senders are handled.
@ IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.5 -all"In this example, Google Workspace (include:_spf.google.com), Mailchimp (include:servers.mcsv.net), and a dedicated server (ip4:203.0.113.5) are defined as authorized senders. The -all at the end instructs the receiving server to reject all emails from unauthorized servers. Use -all (hard fail) instead of ~all (soft fail) for maximum protection.
SPF Limitations and Common Errors
SPF has an important limitation: the record may require a maximum of 10 DNS lookups. Each include counts as one lookup. With many external services like email marketing, CRM, helpdesk, and transactional email, this limit can be reached quickly. Exceeding the limit results in a permanent SPF failure. XICTRAQ checks the number of DNS lookups in the SPF record and warns when approaching the limit.
DKIM: Digital Signature for Email Integrity
DomainKeys Identified Mail (DKIM) goes beyond SPF: it cryptographically signs the email header and optionally the body. The sending server inserts a digital signature in the email header, and the receiving server verifies this signature against a public key stored as a DNS TXT record.
Generating a DKIM Key Pair
DKIM is based on asymmetric cryptography. You generate a key pair: the private key is stored on the sending server and signs outgoing emails. The public key is published as a DNS TXT record under selector._domainkey.your-domain.com. The receiving server retrieves the public key and uses it to verify the signature.
google._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."The selector (here: google) identifies the key pair. You can use multiple DKIM selectors for different services, such as one for your email system and one for your newsletter service. The recommended key length is at least 2048 bits. Shorter keys are considered insecure.
Enabling DKIM with Common Email Providers
Most email providers and services natively support DKIM. With Google Workspace, you enable DKIM in the Admin Console and add the generated DNS record. Microsoft 365 automatically enables DKIM for the default domain and offers manual configuration for custom domains. Newsletter services like Mailchimp and Sendinblue provide DKIM records that you add to your DNS.
DMARC: The Policy for Unauthenticated Emails
Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds on SPF and DKIM and defines what should happen with emails that pass neither SPF nor DKIM. Without DMARC, each receiving server decides on its own how to handle unauthenticated emails. DMARC gives you as the domain owner control back.
DMARC Policies: none, quarantine, reject
DMARC offers three policies: p=none only observes and delivers reports without affecting emails, ideal for starting out. p=quarantine routes unauthenticated emails to the spam folder. p=reject completely rejects unauthenticated emails. The recommended approach: start with p=none, analyze the reports, identify all legitimate senders, and gradually increase to p=quarantine and finally p=reject.
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@your-domain.com; ruf=mailto:dmarc-forensic@your-domain.com; adkim=s; aspf=s; pct=100"In this example, all unauthenticated emails are rejected (p=reject). Aggregate reports go to dmarc-reports@, forensic reports to dmarc-forensic@. The parameters adkim=s and aspf=s enforce strict alignment, meaning the domain in the From header must exactly match the SPF/DKIM domain.
Analyzing DMARC Reports
DMARC reports provide valuable insights into your email traffic. The aggregate reports (rua) show which servers send emails for your domain and whether SPF and DKIM pass. The forensic reports (ruf) provide details on individual failed emails. Without analyzing these reports, you are flying blind: you do not know whether legitimate emails are being blocked or whether spoofing attempts are occurring.
Step-by-Step Setup
Setting up all three protocols follows a logical sequence. Start with SPF, continue with DKIM, and implement DMARC last.
- Inventory: Identify all services that send emails via your domain. These include the primary email system, newsletter services, CRM systems, helpdesk tools, transactional email providers, and the website itself (contact forms).
- Configure SPF: Create an SPF record that includes all identified services. Verify that the 10-lookup limit is not exceeded. Start with ~all and switch to -all after successful verification.
- Enable DKIM: Activate DKIM with every service that sends emails for your domain. Store the public keys as DNS TXT records. Use at least 2048-bit keys.
- Start DMARC with p=none: Create a DMARC record with p=none and a rua address for reports. Monitor reports for at least two weeks.
- Analyze reports: Check that all legitimate emails pass SPF and DKIM. Identify and fix misconfigurations.
- Tighten policy: Gradually increase the DMARC policy: p=quarantine with pct=10, then pct=50, then pct=100, finally p=reject.
Common Configuration Errors and Their Impact
Setting up SPF, DKIM, and DMARC is technically straightforward but error-prone. The most common errors and their impact:
- Multiple SPF records: Only one SPF TXT record per domain is allowed. Multiple records cause a permanent SPF failure.
- SPF lookup limit exceeded: More than 10 include or redirect directives cause a permanent failure. Consolidate services or use SPF flattening.
- DKIM keys not rotated: DKIM keys should be rotated every 6 to 12 months. Stale keys increase compromise risk.
- DMARC without reports: p=reject without a rua address means you will not know which emails are being rejected. Legitimate emails could be silently lost.
- Subdomain policy forgotten: DMARC applies to the main domain by default only. Set sp=reject to protect subdomains as well.
Impact on Email Deliverability and Domain Reputation
Correctly configured email authentication measurably improves delivery rates. According to a Valimail study, domains with DMARC p=reject achieve delivery rates above 95%, while domains without DMARC hover between 70 and 80% (Valimail). Google and Yahoo have filtered emails without SPF and DKIM more aggressively into spam since 2024 (Google). The blacklisting probability drops significantly when spoofing emails are prevented through DMARC p=reject.
For businesses that rely on email marketing, deliverability is a direct revenue factor. When 20% of your newsletters land in spam, you lose 20% of potential readers and customers. A correct SPF/DKIM/DMARC configuration combined with clean website compliance maximizes delivery rates while protecting domain reputation.
Email Authentication and Website Security
Email authentication and website security are closely linked. When an attacker manipulates your domain's DNS records through DNS hijacking, they can both redirect the website and alter SPF and DKIM records to enable spoofing emails. DNSSEC protects the integrity of your DNS records. XICTRAQ monitors DNS records for unexpected changes and notifies you immediately.
Domain expiration protection also plays a role: an expired domain can be registered by third parties and abused for spoofing. XICTRAQ monitors domain expiration dates and warns in advance. In combination with SSL monitoring and security header checks, a holistic security concept for domain, website, and email emerges.
Monitoring: Continuously Watching SPF, DKIM, and DMARC
DNS records can change unintentionally, for example through hosting migrations, DNS provider changes, or manual errors. A missing or incorrect SPF record can collapse delivery rates within hours. XICTRAQ monitors your DNS records with every scan, checking:
- SPF record present, syntactically correct, and under the 10-lookup limit
- DKIM records present and valid for all configured selectors
- DMARC record present with recommended policy (quarantine or reject)
- DMARC alignment correctly configured (adkim, aspf)
- No contradictory or duplicate DNS records
- DNS changes detected and logged
When the status deteriorates, such as an SPF record being accidentally deleted or a DKIM key expiring, you are notified by email. The combination of email authentication monitoring and website security scanning in one platform eliminates blind spots.
Frequently Asked Questions About SPF, DKIM, and DMARC
Do I need all three protocols (SPF, DKIM, DMARC)?
What happens if my SPF record is incorrect?
How long does it take to set up SPF, DKIM, and DMARC?
Can DMARC block my own emails?
How often should I check email authentication?
Does email authentication also protect against phishing?
This article is based on data from: (Google), (Microsoft), DMARC Report (Valimail), DBIR 2024 (Verizon).