SaaSFort An attacker sends an email from [email protected] to your customer’s CFO requesting a wire transfer. If your DMARC policy is p=none, that email lands in the inbox. No warning, no spam filter, no trace back to you until the damage is done.
This isn’t hypothetical. Email spoofing accounts for 1.2% of all email traffic globally (Google Transparency Report 2025). For SaaS companies, the risk is doubled: attackers spoof your domain to target your customers, and enterprise procurement teams check your email authentication as part of vendor security assessments.
SaaSFort scans SPF, DKIM, and DMARC as part of its 60-check security audit. Here’s how to get all three right.
How Email Authentication Works
Three protocols work together to prevent email spoofing. Each solves a different piece of the problem.
SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are authorized to send email for your domain. It’s a DNS TXT record listing your legitimate senders.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving server verifies the signature against a public key in your DNS records. If the email was modified in transit or sent by an unauthorized server, verification fails.
DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together with a policy. It tells receiving servers what to do when authentication fails: nothing (p=none), quarantine (p=quarantine), or reject (p=reject). It also sends you reports about authentication failures.
| Protocol | What It Does | DNS Record Type | Without It |
|---|---|---|---|
| SPF | Authorizes sending IPs | TXT on domain | Anyone can send as your domain |
| DKIM | Signs emails cryptographically | TXT (CNAME) on selector._domainkey | Emails can be modified in transit |
| DMARC | Enforces policy on failures | TXT on _dmarc | No enforcement, no visibility |
All three are required. SPF without DMARC means authentication happens but failures are ignored. DKIM without SPF means signed emails pass but unsigned spoofed emails aren’t blocked. DMARC without both SPF and DKIM has nothing to enforce.
Step 1: Set Up SPF
SPF is a single TXT record on your root domain. It lists every service authorized to send email as your domain.
Basic SPF record for a typical SaaS company:
v=spf1 include:_spf.google.com include:amazonses.com include:sendgrid.net ~all
Common SaaS sending services and their SPF includes:
| Service | SPF Include |
|---|---|
| Google Workspace | include:_spf.google.com |
| Amazon SES | include:amazonses.com |
| SendGrid | include:sendgrid.net |
| Mailgun | include:mailgun.org |
| Postmark | include:spf.mtasv.net |
| HubSpot | include:mail-hub.net |
| Intercom | include:intercom.io |
Critical rules:
- One SPF record per domain. Multiple TXT records starting with
v=spf1break SPF entirely. Merge all includes into one record. - End with
-all(hard fail) or~all(soft fail). Start with~allduring setup, switch to-allafter confirming all legitimate senders are listed. - Stay under 10 DNS lookups. Each
include:costs one lookup. Nested includes count too. Exceeding 10 causes a PermError and SPF fails silently. Use tools like MXToolbox SPF Checker to count. - Don’t forget transactional email. Your app sends password resets, invoices, and notifications. Those services need SPF authorization too.
Step 2: Configure DKIM
DKIM requires two things: your email service generates signed emails, and you publish the verification key in DNS.
For Google Workspace:
- Admin Console → Apps → Google Workspace → Gmail → Authenticate email
- Generate a DKIM key (2048-bit recommended)
- Add the TXT record Google provides to your DNS
- Activate DKIM signing in the Admin Console
For Amazon SES / transactional email: Most transactional services (SES, SendGrid, Postmark) provide CNAME records you add to DNS. They handle key rotation automatically.
Verification: Send a test email and check headers for dkim=pass. Or run a SaaSFort scan — DKIM verification is included in the DNS security category.
Common DKIM mistakes:
- Publishing the key on the wrong subdomain (must be
selector._domainkey.yourdomain.com) - Using 1024-bit keys (2048-bit is the current standard)
- Forgetting to activate DKIM signing after adding the DNS record
- Not configuring DKIM for all sending services (each needs its own selector)
Step 3: Deploy DMARC
DMARC is where enforcement happens. Without it, SPF and DKIM provide information but no protection.
DMARC deployment in three phases:
Phase 1: Monitor (2 weeks)
v=DMARC1; p=none; rua=mailto:[email protected]; pct=100
p=none means: don’t block anything, just send me reports. Use this phase to identify all legitimate email sources. DMARC reports (XML format) show every IP that sent email as your domain and whether SPF/DKIM passed.
Use a free DMARC report analyzer (dmarcian, Postmark DMARC, EasyDMARC) to make the XML readable.
Phase 2: Quarantine (2-4 weeks)
v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25
p=quarantine sends failing emails to spam. Start with pct=25 (only apply to 25% of failing emails) and increase to 100% over several weeks as you confirm no legitimate email is affected.
Phase 3: Reject (permanent)
v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100
p=reject tells receiving servers to drop emails that fail both SPF and DKIM alignment. This is the target state. Enterprise buyers specifically check for p=reject during security assessments.
Timeline: Most SaaS companies can go from p=none to p=reject in 6-8 weeks.
Why Enterprise Buyers Check Your DMARC
Enterprise procurement teams verify email authentication for three reasons:
- Supply chain attack prevention. A spoofed email from your domain to their employees is a supply chain attack. NIS2 Article 21(2)(d) requires managing this risk.
- Vendor risk scoring. Tools like SaaSFort, SecurityScorecard, and BitSight check DMARC policy as part of automated vendor ratings. A
p=noneDMARC drops your score. - DDQ requirements. Security questionnaires now include specific questions about email authentication — “Do you enforce DMARC with p=reject?” is a standard item.
For NIS2-regulated companies, §38 BSIG makes management personally liable for supply chain security oversight. Your DMARC policy is part of the evidence trail your customers need to maintain.
Email Authentication and Your Security Grade
SaaSFort checks SPF, DKIM, and DMARC in its DNS security category. Here’s how each affects your A-F grade:
| Check | Impact if Missing | Fix Difficulty |
|---|---|---|
| SPF record present | Medium severity finding | 5 minutes — add TXT record |
SPF -all enforcement | Low severity | Change ~all to -all |
| DKIM configured | Medium severity | 15 minutes per service |
| DMARC present | High severity finding | 5 minutes — add TXT record |
DMARC p=reject | Medium severity | 6-8 weeks (phased rollout) |
Missing DMARC is a high-severity finding because it means zero protection against email spoofing. Combined with missing HTTP security headers and weak TLS configuration, email authentication gaps can drop your grade by 15-20 points.
The good news: SPF + DKIM + DMARC (p=none) can be deployed in under 30 minutes. Moving to p=reject takes 6-8 weeks of monitoring but requires no engineering effort.
Troubleshooting Common Issues
“SPF PermError: too many DNS lookups” — Flatten your SPF record by replacing include: directives with direct IP ranges for stable services. Each include: costs one lookup; max is 10.
“DKIM signature not found” — Check that DKIM signing is activated, not just the DNS record published. Send a test email and inspect the Authentication-Results header.
“DMARC reports show legitimate email failing” — A sending service lacks SPF/DKIM alignment. Add it to SPF and configure DKIM before increasing enforcement.
“Subdomains aren’t protected” — Use sp=reject in your root DMARC record to cover all subdomains.
FAQ
How long does full email authentication setup take?
SPF + DKIM + DMARC (p=none) can be deployed in under 30 minutes. Moving from p=none to p=reject takes 6-8 weeks of monitoring. No code changes needed — it’s all DNS records.
Does DMARC affect email deliverability?
Properly configured DMARC improves deliverability. Gmail and Microsoft prioritize authenticated email. A p=reject policy signals that spoofed email should be blocked — legitimate email passes through faster. Only misconfigured DMARC (blocking your own legitimate senders) hurts deliverability.
What DMARC policy do enterprise buyers expect?
p=reject. Anything less — p=none or p=quarantine — shows up as a finding in vendor security assessments. Some enterprise TPRM teams auto-flag vendors with p=none as non-compliant.
Is email authentication required by NIS2?
NIS2 Article 21(2)(d) requires supply chain security measures. Email spoofing from vendor domains is a recognized supply chain attack vector. While NIS2 doesn’t name DMARC specifically, implementing p=reject is one of the concrete controls auditors verify. See our NIS2 compliance guide for SaaS.
Can SaaSFort check my email authentication?
Yes. Run a free scan — SPF, DKIM, and DMARC checks are included in the DNS security category. The scan shows whether each protocol is present, correctly configured, and aligned. Results map to NIS2 Article 21(2)(d) and (e). Export as NIS2 compliance PDF.
Check your email authentication now. Free scan — includes SPF, DKIM, and DMARC verification alongside 57 other security checks. A-F grade, NIS2 mapping. Under 60 seconds. Email authentication is one part of your external attack surface — download the SaaS Security Playbook 2026 for the complete framework.
Von der Theorie zur Praxis
Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.