DMARC, SPF & BIMI Brand Security Architect

Why Email Authentication Fails — and How Attackers Exploit It

Email is the most dangerous attack surface in modern enterprise security — not because encryption is weak, but because the protocol that governs who can send email was never designed with authentication in mind. SMTP (Simple Mail Transfer Protocol), standardized in 1982, allows any mail server on the internet to claim any From: address with zero verification. A cybercriminal can send an email reading From: ceo@yourcompany.com from a rented server in any country, and for decades, receiving servers simply delivered it.

The consequences are catastrophic. Business Email Compromise (BEC) attacks — where criminals impersonate executives, vendors, or employees via spoofed email domains — cost organizations $2.9 billion in verified losses in 2023 alone according to the FBI's Internet Crime Complaint Center (IC3). The FBI reports BEC as the single costliest cyber threat category, exceeding ransomware losses by 5x. The average BEC incident costs $125,000. The attack vector is embarrassingly simple: send a convincing email from a spoofed CEO address instructing the CFO to wire transfer funds or change a vendor's bank account details.

Phishing attacks follow the same pattern. 91% of all cyberattacks begin with a phishing email according to Deloitte's cyber threat intelligence reports. When an attacker can make their phishing email appear to come from support@yourbank.com or security@paypal.com, click-through rates become devastatingly high because the domain in the From: field matches the real organization's domain exactly.

DMARC, SPF, and DKIM are the three-protocol stack that closes this gap. Together they allow domain owners to publish cryptographic proof of who is authorized to send email for their domain, and to instruct receiving mail servers to reject or quarantine anything that doesn't meet that proof. This tool builds all three DNS records for you, client-side, with zero data sent anywhere.

The Email Authentication Stack: SPF, DKIM, and DMARC Explained

Each of the three authentication protocols operates at a different layer of email delivery. Understanding the difference is essential to configuring them correctly.

Layer 1: SPF — The IP Allowlist

SPF (Sender Policy Framework, RFC 7208) is the most fundamental layer. You publish a DNS TXT record at your domain's root listing which mail servers, by IP address or hostname, are authorized to send email on behalf of your domain. When a receiving mail server accepts an incoming message, it looks up the SPF record of the RFC5321 MailFrom domain (the envelope sender — this is often hidden from end users) and checks if the connecting server's IP is listed. If it is, SPF passes. If not, it fails. SPF is straightforward but has a critical limitation: it breaks on email forwarding. When an email is forwarded by a third-party server, the connecting IP changes to the forwarder's IP, which won't be on your SPF allowlist.

Layer 2: DKIM — Cryptographic Signing

DKIM (DomainKeys Identified Mail, RFC 6376) takes a fundamentally different approach. Your mail server signs each outgoing email with a private cryptographic key, adding a DKIM-Signature: header to the message. You publish the corresponding public key in a DNS TXT record under a subdomain like mail._domainkey.example.com. Any receiving server can fetch this public key and verify the signature, confirming that the message was actually signed by a server holding the private key for your domain. DKIM signatures survive email forwarding because the signature is embedded in the headers, not the network connection. DKIM's weakness: it doesn't verify the From: header — only the d= domain in the signature header.

Layer 3: DMARC — The Enforcement and Reporting Layer

Neither SPF nor DKIM alone prevents spoofing of the From: header (the address users actually see). A sophisticated attacker can pass SPF using their own domain in the envelope sender while using your domain in the From: header. DMARC (RFC 7489) closes this gap by requiring identifier alignment: the domain that passes SPF or DKIM must align with the From: header domain that users see. If neither SPF nor DKIM are aligned with the From: domain, DMARC fails — and your published DMARC policy instructs the receiving server to quarantine or reject the message. DMARC also provides aggregate reporting: you receive daily XML reports from every major ISP showing you exactly what email is being sent using your domain name, whether it passes or fails authentication, and from which IP addresses.

SPF Records: A Complete Technical Reference

An SPF record is a DNS TXT record published at your domain's root (or subdomain) using the format: v=spf1 [mechanisms] [qualifier]all

All SPF Mechanisms

• ip4:192.0.2.1 — Authorize a single IPv4 address. No DNS lookup consumed.
• ip4:192.0.2.0/24 — Authorize an IPv4 CIDR range. No DNS lookup consumed.
• ip6:2001:db8::1 — Authorize a single IPv6 address. No DNS lookup consumed.
• include:_spf.google.com — Authorize all IPs authorized by _spf.google.com's SPF record. Consumes 1 DNS lookup plus any recursive lookups.
• a — Authorize the A/AAAA records of your domain itself. Consumes 1 lookup.
• a:mail.example.com — Authorize the A record of the specified host. Consumes 1 lookup.
• mx — Authorize all hosts listed in your domain's MX records. Consumes 1 lookup + 1 per MX host.
• redirect=other.example.com — Redirect entire SPF evaluation to another domain's SPF record. Consumes 1 lookup. Cannot be combined with all.
• exists:%{i}._spf.example.com — Advanced macro: authorize if a DNS lookup returns any result. Consumes 1 lookup.
• ptr — Deprecated. Never use. Slow, unreliable, and consumes multiple lookups.

The All Mechanism & Qualifiers

The all mechanism at the end of an SPF record acts as the default catch-all for any IP not matched by earlier mechanisms. The qualifier prefix determines what happens when all fails:

• -all — Hard Fail. Unauthorized senders are explicitly rejected. Strongest setting. May cause false positives if you haven't listed all senders.
• ~all — Soft Fail. Unauthorized senders are accepted but flagged (typically delivered to spam). Recommended for initial deployment.
• ?all — Neutral. No policy statement; treated as if there's no SPF. Essentially useless for security.
• +all — Pass. Authorizes ALL senders. Completely negates SPF security. Never use this.

The Critical 10-Lookup Limit

RFC 7208 limits SPF evaluation to a maximum of 10 DNS lookups during evaluation. The mechanisms that consume lookups are: include, a, mx, ptr, exists, and redirect. ip4 and ip6 are static and consume zero lookups. Exceeding 10 lookups causes a permerror result, which DMARC treats as an SPF authentication failure — even if the sending IP would have been authorized. This is a hard technical limit, not a best-practice guideline.

Our SPF builder's lookup counter tracks this for you in real time. When you see the badge turn yellow at 7 lookups, it's time to consolidate your include: statements using SPF flattening.

DMARC Policy Levels: none, quarantine, reject — When to Use Each

Implementing DMARC is not a binary switch — it's a graduated enforcement process. Jumping directly to p=reject on day one without first mapping all legitimate email sources is a common mistake that causes legitimate business email to be rejected by receiving servers. The correct approach is the DMARC ramp-up ladder.

Stage 1: p=none (Monitoring Mode)

Start with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;. This tells receiving servers to take no action on email that fails DMARC — deliver it normally, but send you daily aggregate reports. Spend 2-4 weeks analyzing these reports. You'll discover all the email sources sending on behalf of your domain: marketing automation tools, CRM systems, help desk platforms, external partners. Ensure each one either passes SPF or DKIM alignment, or update your SPF record to include them.

Stage 2: p=quarantine at Low pct

Once you're confident 95%+ of legitimate email passes DMARC, move to p=quarantine; pct=5;. This quarantines 5% of failing messages (sends them to spam) while delivering the other 95% normally. Monitor your rua reports for legitimate mail caught by quarantine. Gradually increase pct: 5 → 25 → 50 → 100 over several weeks.

Stage 3: p=reject at pct=100

p=reject is the gold standard for domain protection. Receiving SMTP servers that support DMARC will issue a 5xx permanent rejection to the sending server for any non-conforming email — it is never delivered to any inbox. This is the level required for BIMI eligibility. Getting here means you've audited all email sources, all are properly authenticated, and you're confident in blocking everything else.

Important: Using pct=<100 with p=reject means only that percentage of failing email is rejected; the remainder is quarantined (not delivered normally). pct cannot make policy softer than quarantine for the non-sampled messages.

Identifier Alignment: The Core of DMARC Logic

Identifier alignment is DMARC's mechanism for closing the gap that SPF and DKIM alone cannot close. It requires that the domain that authenticated (via SPF or DKIM) must be the same domain shown to the user in the From: header.

SPF Alignment

SPF alignment compares two domains: (1) the RFC5321 MailFrom domain (also called the "envelope sender" or Return-Path — the domain used for bounce handling, often hidden from users) and (2) the RFC5322 From header domain (what users see in their email client). For SPF alignment to pass, these two domains must align according to your configured alignment mode.

DKIM Alignment

DKIM alignment compares the d= value in the DKIM-Signature header with the From: header domain. If the signing domain (d=) aligns with the From: domain, DKIM alignment passes.

Relaxed vs. Strict Alignment

• Relaxed alignment (adkim=r; aspf=r) — The default. Organizational domain matching: mail.example.com aligns with example.com because they share the same organizational domain. Use relaxed alignment when you send from subdomains but want alignment with the parent domain.
• Strict alignment (adkim=s; aspf=s) — Exact domain match required. mail.example.com does NOT align with example.com under strict mode. Use strict alignment only if you have a specific security requirement and complete control over your entire email infrastructure.

DMARC passes if either SPF alignment OR DKIM alignment passes. You only need one of the two to pass — but having both configured provides redundancy against forwarding-induced SPF failures.

DMARC Aggregate Reports (rua): What They Contain and How to Read Them

Aggregate reports (specified via the rua= tag) are the intelligence backbone of DMARC deployment. Every major ISP that processes email claiming to be from your domain — Gmail, Yahoo, Outlook, Apple Mail — sends you an XML report every 24 hours (default interval, controlled by ri=). These reports are compressed as .gz files attached to automated emails.

What Each Report Contains

• Reporting organization — Which ISP is sending the report (e.g., google.com, yahoo.com, hotmail.com)
• Date range — The 24-hour window covered by the report
• Source IP addresses — Every IP that sent email claiming to be from your domain during that period
• Message counts — How many emails from each source IP
• SPF result — Pass, fail, softfail, neutral, none, temperror, or permerror
• DKIM result — Pass or fail (and which selector was found)
• DMARC disposition — None (delivered), quarantine, or reject — the action actually taken
• Header From domain — The From: domain seen by the user

At scale, a large organization will receive hundreds of these reports daily. Parsing XML manually is impractical. The industry has responded with a category of DMARC reporting platforms: Postmark's DMARC Digests (free for low volume), Dmarcian, EasyDMARC, Valimail, and others that aggregate and visualize this data. The rua email address in your DMARC record can be a third-party report parsing service's address.

Cross-Domain rua Reporting

If your reporting email is at a different domain than your DMARC record (e.g., DMARC record at example.com but rua=mailto:dmarc@reportingservice.com), the receiving ISP will first check if reportingservice.com has published a record at example.com._report._dmarc.reportingservice.com that grants permission. Without this delegation record, ISPs (including Gmail) will not deliver reports to the cross-domain address.

Forensic Reports (ruf): Individual Failure Deep-Dive

Forensic reports (specified via ruf=) are near-real-time per-message failure reports. Unlike aggregate reports which are statistical summaries, forensic reports describe individual messages that failed DMARC authentication. They contain email headers (From, To, Subject, Date, MIME structure — but NOT the body) plus the SPF and DKIM evaluation results for that specific message.

The fo= (Failure Options) tag controls which failure scenarios generate a forensic report:

• fo=0 — Generate report only when both SPF and DKIM fail (default)
• fo=1 — Generate report when either SPF or DKIM fails
• fo=d — Generate report when DKIM fails, even if SPF passes
• fo=s — Generate report when SPF fails, even if DKIM passes

Critical caveat: Most major ISPs have stopped sending forensic reports. Gmail discontinued ruf delivery in 2022. Microsoft never supported it. Yahoo and some smaller providers still send them. If you receive no forensic reports, this is normal — your rua configuration is what matters for ongoing monitoring. Forensic reports also carry GDPR implications: even header-only reports can contain PII (recipient email addresses, subject lines). Many organizations omit the ruf tag entirely for privacy compliance.

BIMI: Showing Your Brand Logo in Recipients' Inboxes

Brand Indicators for Message Identification (BIMI) is the standard that rewards organizations that have achieved full DMARC enforcement (p=reject or p=quarantine) with the ability to display their company logo in email clients. The logo appears in the sender avatar area — the round icon next to the sender's name before the recipient opens the email. For recipients, this is a powerful visual trust signal: seeing your recognizable brand logo tells them the email is legitimate before they even open it.

Which Email Clients Support BIMI?

• Gmail — Full support with VMC required for the blue verified checkmark. Without VMC, logo shown for some senders at Google's discretion.
• Yahoo Mail — Supports BIMI without VMC for domains with p=reject or p=quarantine.
• Apple Mail (iOS 16+, macOS Ventura+) — Supports BIMI. VMC handling implementation-specific.
• Fastmail — Supports BIMI for authenticated senders.
• Zoho Mail — Supports BIMI.
• Outlook / Microsoft 365 — Does NOT currently support BIMI but has announced planned implementation. Uses its own sender icon system.

BIMI DNS Record Structure

A BIMI record is published as a TXT record at [selector]._bimi.yourdomain.com. The default selector creates a record at default._bimi.yourdomain.com. The record contains two main tags: l= (logo URL, pointing to your SVG Tiny PS file served over HTTPS) and optionally a= (authority evidence / VMC certificate URL, a .pem file served over HTTPS). Example: v=BIMI1; l=https://yourdomain.com/brand/logo.svg; a=https://yourdomain.com/brand/vmc.pem;

If you have no VMC certificate, publish the record with an empty a= or omit it entirely. Gmail will show the logo only if the a= points to a valid VMC issued by DigiCert or Entrust. Yahoo and Apple Mail do not require the a= field.

SVG Tiny PS: The Strict Logo Format BIMI Requires

The most common reason BIMI implementations fail is the logo format. BIMI requires SVG Tiny 1.2 Portable/Secure (SVG Tiny PS) — a highly restricted subset of the full SVG specification. This is not the SVG format exported by Figma, Adobe Illustrator, Inkscape, or any standard design tool. Standard SVG files almost universally contain elements that SVG Tiny PS forbids.

What SVG Tiny PS Prohibits

• JavaScript — <script> elements or on* event attributes are forbidden
• External resources — xlink:href pointing to external URLs for images or fonts
• Embedded raster images — <image> elements with base64-encoded PNG/JPG
• <foreignObject> — embedding external XML/HTML namespaces
• CSS stylesheets via <style> blocks — styles must be inline attributes
• Animation elements — <animate>, <animateTransform>
• Text elements using external font references

SVG Tiny PS Mandatory Requirements

• Root <svg> element must have: baseProfile="tiny-ps" and version="1.2"
• A valid XML declaration: <?xml version="1.0" encoding="UTF-8"?>
• Correct SVG namespace: xmlns="http://www.w3.org/2000/svg"
• Square viewport: viewBox must have equal width and height
• title element inside root <svg> for accessibility
• File served over HTTPS with correct MIME type image/svg+xml

Use the BIMI Group's SVG validator to check your logo before publishing your BIMI record. Many vendors offer SVG Tiny PS conversion services. Canva's brand export supports BIMI-compliant SVG format. Adobe Illustrator users need the SVG Tiny PS plugin.

SPF Flattening: Solving the 10-Lookup Limit at Enterprise Scale

Organizations using many email providers quickly hit the 10 DNS lookup ceiling. Consider a typical marketing-forward company: Google Workspace (1 lookup), Salesforce Marketing Cloud (2 lookups), HubSpot (1 lookup), Mailchimp (1 lookup), Zendesk (1 lookup), Twilio SendGrid (1 lookup), Amazon SES (1 lookup). That's 8 lookups before accounting for any recursive includes. Add a CRM's transactional email service or a partner's ESP and you've crossed 10.

SPF Flattening Explained

SPF flattening resolves all include: mechanisms recursively at the time of flattening, replacing them with the raw ip4: and ip6: CIDR ranges they resolve to. The resulting SPF record has zero DNS lookups. Instead of include:_spf.google.com, your record directly lists Google's actual IP ranges: ip4:35.190.247.0/24 ip4:64.233.160.0/19 ...

The staleness problem: Google, SendGrid, Salesforce, and other vendors update their IP ranges periodically. A flattened record becomes inaccurate the moment a vendor changes their ranges, causing legitimate email to fail SPF. This requires either (a) automated SPF flattening services that re-flatten daily, or (b) SPF Macros (RFC 7208 Section 7) using the %{i} and %{d} tokens for dynamic per-sender evaluation.

Dynamic SPF Optimization Services

Services like Valimail, dmarcian, and AuthSMTP offer managed SPF optimization. You publish a single include: pointing to their service, which dynamically maintains the correct, up-to-date SPF record for all your email providers. This solves both the lookup limit and the staleness problem simultaneously.

8 Critical Email Authentication Mistakes That Destroy Deliverability

1. Leaving DMARC at p=none indefinitely. p=none provides zero protection — it's monitoring only. Organizations set it up, never analyze the rua reports, and never advance to enforcement. After 60-90 days of monitoring, advance to quarantine.
2. Using +all in SPF. v=spf1 +all authorizes every server on the internet to send email for your domain. This is functionally equivalent to having no SPF record at all and actually worse because it signals you've misconfigured intentionally.
3. Multiple SPF records. Your domain must have exactly one SPF TXT record. Publishing two records is invalid and causes permerror. If you need to add mechanisms, edit the existing record — don't add a second one.
4. Forgetting transactional email services. When you add a new CRM, helpdesk platform, or marketing tool, if it sends email on your behalf and isn't in your SPF record or DKIM-signed, those emails will fail authentication.
5. Incorrect rua cross-domain delegation. If your DMARC rua address is at a different domain, you must publish a delegation record at that domain or ISPs won't send reports. The delegation record format: TXT record at yourdomain.com._report._dmarc.reportingdomain.com with value v=DMARC1;.
6. BIMI without p=quarantine or p=reject. BIMI requires DMARC enforcement. Publishing a BIMI record while DMARC is at p=none will result in no logo display in any email client.
7. SPF record exceeding 255 characters. A single DNS TXT string can be at most 255 bytes. SPF records with many mechanisms may exceed this. The solution is to use multiple quoted strings within the TXT record that the DNS resolver concatenates: "v=spf1 ip4:1.2.3.4" "ip4:5.6.7.8 ~all".
8. DKIM key rotation neglect. DKIM private keys should be rotated at least annually. Compromise of a DKIM private key allows an attacker to sign malicious emails as your domain indefinitely until you rotate. Many organizations set up DKIM once and never change the key.

DMARC Tool Comparison: Why Most Free Generators Fall Short

The market for DMARC record generators ranges from basic one-field tools to enterprise SaaS platforms. Free online generators typically generate a static DMARC string but lack SPF construction, BIMI generation, validation feedback, and privacy guarantees.

Step-by-Step: Deploying DMARC for Google Workspace and Microsoft 365

For Google Workspace

1. Set up DKIM in Google Admin Console → Apps → Google Workspace → Gmail → Authenticate email. Generate a 2048-bit DKIM key and publish the provided TXT record to your DNS.
2. Build your SPF record using this tool. Add the Google Workspace preset (include:_spf.google.com). Add any other sending services. Use ~all initially.
3. Publish your SPF record as a TXT record at @ (root) in your DNS provider. In Cloudflare: DNS → Add record → Type: TXT → Name: @ → Content: your SPF string.
4. Publish a DMARC record at p=none with a valid rua address: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; as a TXT record at the host _dmarc.
5. Verify with dig: dig TXT yourdomain.com @8.8.8.8 (SPF) and dig TXT _dmarc.yourdomain.com @8.8.8.8 (DMARC).
6. Monitor rua reports for 4-6 weeks. Advance to quarantine, then reject, using the pct slider to gradually increase enforcement.

For Microsoft 365

1. Enable DKIM signing in the Microsoft 365 Defender portal → Email & Collaboration → Policies & Rules → Threat policies → Email authentication settings → DKIM. Enable DKIM for your domain and publish the two CNAME records Microsoft provides.
2. SPF record: v=spf1 include:spf.protection.outlook.com -all for Microsoft 365 only. Add additional includes for any other mail services.
3. DMARC record: Same structure as above but publish at _dmarc.yourdomain.com TXT with your chosen policy and rua.
4. Note on Office 365 and DMARC p=reject: Microsoft's inbound filtering also does DMARC evaluation. For outbound, Microsoft DKIM signing aligns the d= with your domain when configured correctly.

Frequently Asked Questions

Explore More Security & Developer Tools

Discover more privacy-first, client-side tools in our collection — all processing happens in your browser, zero uploads required.