[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-fff171ff-7db6-4819-a366-1de2e7705479":3},{"id":4,"body":5,"uuid":6,"created_at":7,"updated_at":8,"brand":9,"header":10,"short_body":11,"image":12,"published":13,"published_at":14,"tags":15},12,"\u003Cp>If your transactional emails land in spam, get silently dropped, or trigger \"via\" warnings in Gmail, the root cause is almost always email authentication. \u003Cstrong>SPF, DKIM, and DMARC\u003C\u002Fstrong> are the three DNS-based standards that let receiving mail servers verify that a message claiming to be from \u003Ccode>yourdomain.com\u003C\u002Fcode> actually came from a server you authorized — and that it wasn't tampered with in transit. Get them right and your password resets, receipts, and verification codes reach the inbox. Get them wrong and a single misconfigured record can quietly destroy your deliverability.\u003C\u002Fp>\n\u003Cp>This guide explains how SPF, DKIM, and DMARC work together, shows you the exact DNS records to publish, and walks through the mistakes that trip up most engineering teams. It's written for SaaS founders, software engineers, and CTOs who need email to \u003Cem>just work\u003C\u002Fem> — without becoming part-time email administrators.\u003C\u002Fp>\n\u003Ch2>What Is Email Authentication?\u003C\u002Fh2>\n\u003Cp>Email authentication is a set of protocols that prove an email is legitimately from the domain it claims to be from. The original SMTP protocol, designed in the early 1980s, has \u003Cstrong>no built-in identity verification\u003C\u002Fstrong> — anyone can connect to a mail server and claim to be \u003Ccode>support@yourbank.com\u003C\u002Fcode>. That open design is why phishing and spoofing remain the most common attack vectors today.\u003C\u002Fp>\n\u003Cp>The three core standards solve this problem from different angles:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Standard\u003C\u002Fth>\n\u003Cth>What it verifies\u003C\u002Fth>\n\u003Cth>Where it's published\u003C\u002Fth>\n\u003Cth>Year standardized\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>SPF\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>Which servers are allowed to send for your domain\u003C\u002Ftd>\n\u003Ctd>DNS TXT record\u003C\u002Ftd>\n\u003Ctd>2014 (RFC 7208)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>DKIM\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>That the message wasn't altered and came from your domain\u003C\u002Ftd>\n\u003Ctd>DNS TXT record + email header signature\u003C\u002Ftd>\n\u003Ctd>2011 (RFC 6376)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>DMARC\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>What receivers should do when SPF\u002FDKIM fail, plus reporting\u003C\u002Ftd>\n\u003Ctd>DNS TXT record\u003C\u002Ftd>\n\u003Ctd>2015 (RFC 7489)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>Think of it like a sealed, signed letter:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>SPF\u003C\u002Fstrong> is the approved list of post offices allowed to mail on your behalf.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>DKIM\u003C\u002Fstrong> is the wax seal that proves the letter wasn't opened and resealed.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>DMARC\u003C\u002Fstrong> is the instruction to the recipient: \"if the post office isn't on my list \u003Cem>and\u003C\u002Fem> the seal is broken, reject the letter — and send me a report either way.\"\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>None of these is optional anymore. Since February 2024, \u003Cstrong>Google and Yahoo require SPF, DKIM, and DMARC\u003C\u002Fstrong> for bulk senders, and they increasingly scrutinize transactional senders too. Microsoft began enforcing similar requirements for high-volume senders in 2025.\u003C\u002Fp>\n\u003Ch2>How SPF Works (Sender Policy Framework)\u003C\u002Fh2>\n\u003Cp>SPF lets you publish a list of IP addresses and servers authorized to send email on behalf of your domain. When a receiving server gets a message, it looks up the SPF record of the domain in the \u003Ccode>Return-Path\u003C\u002Fcode> (also called the envelope sender or \u003Ccode>MAIL FROM\u003C\u002Fcode>) and checks whether the connecting IP is on the approved list.\u003C\u002Fp>\n\u003Ch3>The SPF DNS record\u003C\u002Fh3>\n\u003Cp>An SPF record is a single DNS \u003Ccode>TXT\u003C\u002Fcode> record on your sending domain. Here's a typical one:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-dns\">yourdomain.com.  IN  TXT  "v=spf1 include:_spf.postwing.app include:_spf.google.com -all"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Breaking that down:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ccode>v=spf1\u003C\u002Fcode> — declares this is an SPF version 1 record.\u003C\u002Fli>\n\u003Cli>\u003Ccode>include:_spf.postwing.app\u003C\u002Fcode> — authorizes Postwing's sending infrastructure.\u003C\u002Fli>\n\u003Cli>\u003Ccode>include:_spf.google.com\u003C\u002Fcode> — authorizes Google Workspace to send (for your regular business mail).\u003C\u002Fli>\n\u003Cli>\u003Ccode>-all\u003C\u002Fcode> — the \u003Cstrong>qualifier\u003C\u002Fstrong> that tells receivers what to do with everything else.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>SPF qualifiers explained\u003C\u002Fh3>\n\u003Cp>The trailing mechanism is the most important and most misunderstood part of SPF:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Qualifier\u003C\u002Fth>\n\u003Cth>Meaning\u003C\u002Fth>\n\u003Cth>Behavior on failure\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Ccode>-all\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>Hard fail\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>Reject unauthorized senders. Strongest.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>~all\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>Soft fail\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>Accept but mark suspicious. Common during rollout.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>?all\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>Neutral\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>No opinion. Provides almost no protection.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>+all\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>Pass all\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>Allows \u003Cem>anyone\u003C\u002Fem> to send. Never use this.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>Start with \u003Ccode>~all\u003C\u002Fcode> while you confirm every legitimate sender is included, then tighten to \u003Ccode>-all\u003C\u002Fcode> once you're confident.\u003C\u002Fp>\n\u003Ch3>The SPF 10-lookup limit\u003C\u002Fh3>\n\u003Cp>SPF has a hard rule that catches almost every growing team: \u003Cstrong>a maximum of 10 DNS lookups\u003C\u002Fstrong> per evaluation. Each \u003Ccode>include\u003C\u002Fcode>, \u003Ccode>a\u003C\u002Fcode>, \u003Ccode>mx\u003C\u002Fcode>, \u003Ccode>ptr\u003C\u002Fcode>, and \u003Ccode>redirect\u003C\u002Fcode> mechanism counts. Exceed 10 and SPF returns a \u003Ccode>permerror\u003C\u002Fcode>, which most receivers treat as a failure — silently breaking authentication for \u003Cem>all\u003C\u002Fem> your mail.\u003C\u002Fp>\n\u003Cp>A common cause is stacking too many providers:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-dns\"># This can easily blow past 10 lookups\n"v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:_spf.salesforce.com include:mail.zendesk.com -all"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>To stay under the limit, use \u003Cstrong>SPF flattening\u003C\u002Fstrong> (replacing includes with their resolved IP ranges) or consolidate senders. A well-designed provider like Postwing publishes a single, lookup-efficient \u003Ccode>include\u003C\u002Fcode> so you don't burn your budget on one vendor.\u003C\u002Fp>\n\u003Ch3>SPF's weakness: it breaks on forwarding\u003C\u002Fh3>\n\u003Cp>SPF checks the envelope sender's IP. When an email is \u003Cstrong>forwarded\u003C\u002Fstrong>, the forwarding server becomes the new sending IP — which isn't on your SPF list — so SPF fails. This is why SPF alone is not enough, and why DKIM and DMARC exist.\u003C\u002Fp>\n\u003Ch2>How DKIM Works (DomainKeys Identified Mail)\u003C\u002Fh2>\n\u003Cp>DKIM uses public-key cryptography to attach a tamper-proof digital signature to every outgoing message. Unlike SPF, which checks the \u003Cem>connection\u003C\u002Fem>, DKIM verifies the \u003Cem>content and headers\u003C\u002Fem> of the email itself — so it survives forwarding.\u003C\u002Fp>\n\u003Ch3>The signing and verification flow\u003C\u002Fh3>\n\u003Col>\n\u003Cli>Your sending server (or provider) generates a \u003Cstrong>private\u002Fpublic key pair\u003C\u002Fstrong>.\u003C\u002Fli>\n\u003Cli>The \u003Cstrong>public key\u003C\u002Fstrong> is published as a DNS TXT record at a \"selector\" subdomain.\u003C\u002Fli>\n\u003Cli>For each outgoing email, the server hashes selected headers and the body, then signs that hash with the \u003Cstrong>private key\u003C\u002Fstrong>, adding a \u003Ccode>DKIM-Signature\u003C\u002Fcode> header.\u003C\u002Fli>\n\u003Cli>The receiving server reads the signature, fetches your public key from DNS, and verifies the signature mathematically.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>If the body or signed headers were altered in transit, verification fails.\u003C\u002Fp>\n\u003Ch3>The DKIM DNS record\u003C\u002Fh3>\n\u003Cp>The public key lives at \u003Ccode><selector>._domainkey.yourdomain.com\u003C\u002Fcode>. The selector lets you run multiple keys (e.g., per provider or for key rotation):\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-dns\">pw1._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7..."\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>And the resulting header on a signed message looks like this:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>DKIM-Signature: v=1; a=rsa-sha256; c=relaxed\u002Frelaxed;\n  d=yourdomain.com; s=pw1;\n  h=from:to:subject:date:message-id;\n  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;\n  b=AuUoFEfDxTDkHlLXSZEpZj79LICXz...\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Key fields:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ccode>d=\u003C\u002Fcode> — the signing \u003Cstrong>domain\u003C\u002Fstrong>.\u003C\u002Fli>\n\u003Cli>\u003Ccode>s=\u003C\u002Fcode> — the \u003Cstrong>selector\u003C\u002Fstrong> pointing to the public key.\u003C\u002Fli>\n\u003Cli>\u003Ccode>bh=\u003C\u002Fcode> — the \u003Cstrong>body hash\u003C\u002Fstrong>.\u003C\u002Fli>\n\u003Cli>\u003Ccode>b=\u003C\u002Fcode> — the actual cryptographic signature.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>DKIM key length and rotation\u003C\u002Fh3>\n\u003Cp>Use \u003Cstrong>2048-bit RSA keys\u003C\u002Fstrong>, not 1024-bit. Google now flags messages signed with short keys, and 1024-bit keys are considered weak. Rotate keys periodically (every 6–12 months is a reasonable cadence) by publishing a new selector before retiring the old one — this avoids any signing gap.\u003C\u002Fp>\n\u003Ch2>How DMARC Works (Domain-based Message Authentication)\u003C\u002Fh2>\n\u003Cp>DMARC ties SPF and DKIM together and adds two critical capabilities: a \u003Cstrong>published policy\u003C\u002Fstrong> telling receivers what to do with failures, and \u003Cstrong>aggregate reporting\u003C\u002Fstrong> so you can see who's sending mail as your domain.\u003C\u002Fp>\n\u003Ch3>Alignment: the concept that makes DMARC work\u003C\u002Fh3>\n\u003Cp>DMARC introduces the concept of \u003Cstrong>alignment\u003C\u002Fstrong>. It's not enough for SPF or DKIM to merely \u003Cem>pass\u003C\u002Fem> — the domain they authenticate must \u003Cem>align\u003C\u002Fem> with the domain in the visible \u003Ccode>From:\u003C\u002Fcode> header that users actually see.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>SPF alignment\u003C\u002Fstrong>: the \u003Ccode>Return-Path\u003C\u002Fcode> domain matches the \u003Ccode>From:\u003C\u002Fcode> domain.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>DKIM alignment\u003C\u002Fstrong>: the DKIM \u003Ccode>d=\u003C\u002Fcode> domain matches the \u003Ccode>From:\u003C\u002Fcode> domain.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>DMARC passes if \u003Cstrong>at least one\u003C\u002Fstrong> of SPF or DKIM passes \u003Cem>and\u003C\u002Fem> is aligned. This is why a forwarded email can still pass DMARC: even if SPF breaks, an aligned DKIM signature survives.\u003C\u002Fp>\n\u003Cp>Alignment can be \u003Cstrong>strict\u003C\u002Fstrong> (exact domain match) or \u003Cstrong>relaxed\u003C\u002Fstrong> (organizational domain match — e.g., \u003Ccode>mail.yourdomain.com\u003C\u002Fcode> aligns with \u003Ccode>yourdomain.com\u003C\u002Fcode>). Relaxed is the default and the right choice for most teams.\u003C\u002Fp>\n\u003Ch3>The DMARC DNS record\u003C\u002Fh3>\n\u003Cp>DMARC is published at \u003Ccode>_dmarc.yourdomain.com\u003C\u002Fcode>:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-dns\">_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r; fo=1"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Tag\u003C\u002Fth>\n\u003Cth>Purpose\u003C\u002Fth>\n\u003Cth>Common values\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Ccode>p\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Policy for failures\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>none\u003C\u002Fcode>, \u003Ccode>quarantine\u003C\u002Fcode>, \u003Ccode>reject\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>rua\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Address for aggregate reports\u003C\u002Ftd>\n\u003Ctd>a mailbox you monitor\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>ruf\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Address for forensic reports\u003C\u002Ftd>\n\u003Ctd>optional, privacy-sensitive\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>pct\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Percentage of mail the policy applies to\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>1\u003C\u002Fcode>–\u003Ccode>100\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>adkim\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>DKIM alignment mode\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>r\u003C\u002Fcode> (relaxed) or \u003Ccode>s\u003C\u002Fcode> (strict)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>aspf\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>SPF alignment mode\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>r\u003C\u002Fcode> or \u003Ccode>s\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>sp\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Policy for subdomains\u003C\u002Ftd>\n\u003Ctd>inherits \u003Ccode>p\u003C\u002Fcode> if omitted\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Ch3>The three DMARC policies\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>\u003Cstrong>\u003Ccode>p=none\u003C\u002Fcode>\u003C\u002Fstrong> — Monitor only. Receivers take no action but send you reports. Always start here.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>\u003Ccode>p=quarantine\u003C\u002Fcode>\u003C\u002Fstrong> — Send failing mail to spam\u002Fjunk.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>\u003Ccode>p=reject\u003C\u002Fcode>\u003C\u002Fstrong> — Reject failing mail outright. This is the goal.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Roughly \u003Cstrong>70% of domains\u003C\u002Fstrong> that publish a DMARC record never move past \u003Ccode>p=none\u003C\u002Fcode>, which means they get reporting but no actual protection against spoofing. Your target should be \u003Ccode>p=reject\u003C\u002Fcode> once your reports show all legitimate mail passing.\u003C\u002Fp>\n\u003Ch2>Step-by-Step: Setting Up SPF, DKIM, and DMARC\u003C\u002Fh2>\n\u003Cp>Here's a practical rollout sequence that won't break your existing mail flow.\u003C\u002Fp>\n\u003Ch3>1. Inventory every service that sends as your domain\u003C\u002Fh3>\n\u003Cp>Before publishing anything, list every sender: your email provider (Google\u002FMicrosoft), your transactional provider (Postwing), your CRM, your support desk, your marketing tool, your billing platform. Each one needs to be authorized.\u003C\u002Fp>\n\u003Ch3>2. Publish SPF\u003C\u002Fh3>\n\u003Cp>Combine all authorized senders into one record and start with a soft fail:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-dns\">yourdomain.com.  IN  TXT  "v=spf1 include:_spf.postwing.app include:_spf.google.com ~all"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Verify it resolves and stays under 10 lookups using a checker tool.\u003C\u002Fp>\n\u003Ch3>3. Enable DKIM\u003C\u002Fh3>\n\u003Cp>Generate keys in your provider's dashboard. Postwing, for example, gives you the exact TXT records to paste. Publish each provider's selector:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-dns\">pw1._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."\ngoogle._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Send a test email to a Gmail account, open \u003Cstrong>Show original\u003C\u002Fstrong>, and confirm \u003Ccode>DKIM: 'PASS'\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch3>4. Publish DMARC in monitoring mode\u003C\u002Fh3>\n\u003Cp>Start with \u003Ccode>p=none\u003C\u002Fcode> so nothing gets blocked while you observe:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-dns\">_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>5. Read your reports, then enforce\u003C\u002Fh3>\n\u003Cp>DMARC aggregate (\u003Ccode>rua\u003C\u002Fcode>) reports arrive as XML, typically daily. Use a DMARC monitoring service to make them readable. Once reports show 100% of your legitimate mail passing with alignment, ramp up:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>p=none  →  p=quarantine; pct=25  →  p=quarantine; pct=100  →  p=reject\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Give each stage a week or two. This gradual rollout is the single most reliable way to reach \u003Ccode>p=reject\u003C\u002Fcode> without losing real email.\u003C\u002Fp>\n\u003Ch2>How to Verify Authentication Passes\u003C\u002Fh2>\n\u003Cp>The fastest check is the \u003Cstrong>Show original\u003C\u002Fstrong> view in Gmail (or \u003Cstrong>View message source\u003C\u002Fstrong> in Outlook). Look for:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>SPF:    PASS with IP 203.0.113.10\nDKIM:   'PASS' with domain yourdomain.com\nDMARC:  'PASS'\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>For command-line verification, you can inspect the published records directly:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\"># Check SPF\ndig +short TXT yourdomain.com\n\n# Check DKIM for a given selector\ndig +short TXT pw1._domainkey.yourdomain.com\n\n# Check DMARC\ndig +short TXT _dmarc.yourdomain.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>You can also send a message to a free authentication-check mailbox (such as the ones offered by mail-tester or Google's Postmaster Tools) to get a full pass\u002Ffail breakdown.\u003C\u002Fp>\n\u003Ch2>Common Mistakes With SPF, DKIM, and DMARC\u003C\u002Fh2>\n\u003Cp>These are the errors that quietly wreck deliverability — even for teams that \u003Cem>think\u003C\u002Fem> they've set everything up correctly.\u003C\u002Fp>\n\u003Ch3>Publishing multiple SPF records\u003C\u002Fh3>\n\u003Cp>A domain may have \u003Cstrong>only one\u003C\u002Fstrong> SPF record. Two \u003Ccode>v=spf1\u003C\u002Fcode> TXT records cause a \u003Ccode>permerror\u003C\u002Fcode> and SPF fails entirely. If you add a new provider, merge its \u003Ccode>include\u003C\u002Fcode> into your existing record — never create a second one.\u003C\u002Fp>\n\u003Ch3>Exceeding the 10-lookup limit\u003C\u002Fh3>\n\u003Cp>As covered above, stacking too many \u003Ccode>include:\u003C\u002Fcode> mechanisms breaks SPF silently. Audit your lookup count whenever you add a sender.\u003C\u002Fp>\n\u003Ch3>Using \u003Ccode>+all\u003C\u002Fcode> or \u003Ccode>?all\u003C\u002Fcode>\u003C\u002Fh3>\n\u003Cp>\u003Ccode>+all\u003C\u002Fcode> authorizes the entire internet to send as you. \u003Ccode>?all\u003C\u002Fcode> provides no protection. Always end with \u003Ccode>~all\u003C\u002Fcode> (during rollout) or \u003Ccode>-all\u003C\u002Fcode> (in production).\u003C\u002Fp>\n\u003Ch3>Forgetting subdomains\u003C\u002Fh3>\n\u003Cp>If you send transactional mail from \u003Ccode>mail.yourdomain.com\u003C\u002Fcode> but only authenticate \u003Ccode>yourdomain.com\u003C\u002Fcode>, the subdomain mail fails. Set the \u003Ccode>sp\u003C\u002Fcode> tag in DMARC and publish records for each sending subdomain.\u003C\u002Fp>\n\u003Ch3>Jumping straight to \u003Ccode>p=reject\u003C\u002Fcode>\u003C\u002Fh3>\n\u003Cp>Going from no DMARC to \u003Ccode>p=reject\u003C\u002Fcode> without monitoring will reject legitimate mail from senders you forgot to authorize. Always start at \u003Ccode>p=none\u003C\u002Fcode> and read reports first.\u003C\u002Fp>\n\u003Ch3>Ignoring DMARC reports\u003C\u002Fh3>\n\u003Cp>The reports exist for a reason: they reveal shadow IT (that marketing tool someone signed up for), spoofing attempts, and misconfigured senders. A \u003Ccode>p=none\u003C\u002Fcode> record you never look at protects nothing.\u003C\u002Fp>\n\u003Ch3>Mismatched From and Return-Path domains\u003C\u002Fh3>\n\u003Cp>Many \"set it and forget it\" failures come from alignment, not authentication. SPF can pass while DMARC fails because the \u003Ccode>Return-Path\u003C\u002Fcode> domain doesn't match the visible \u003Ccode>From:\u003C\u002Fcode> domain. A good provider lets you use a custom Return-Path (a CNAME) on your own domain to fix this.\u003C\u002Fp>\n\u003Ch3>Letting DKIM keys go stale\u003C\u002Fh3>\n\u003Cp>A 1024-bit key from years ago, or a key your provider rotated without you updating DNS, causes signature failures. Verify your selector still resolves to a current key after any provider change.\u003C\u002Fp>\n\u003Ch2>Why This Matters for SaaS and Transactional Email\u003C\u002Fh2>\n\u003Cp>For a SaaS company, transactional email \u003Cem>is\u003C\u002Fem> part of the product. A password reset that never arrives is a locked-out customer. A verification code in spam is a failed signup. An invoice that bounces is delayed revenue.\u003C\u002Fp>\n\u003Cp>The data backs this up:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Domains with a \u003Ccode>p=reject\u003C\u002Fcode> DMARC policy see measurably \u003Cstrong>higher inbox placement\u003C\u002Fstrong> because mailbox providers treat authenticated senders as more trustworthy.\u003C\u002Fli>\n\u003Cli>BIMI (Brand Indicators for Message Identification) — the standard that displays your logo next to authenticated emails in Gmail and Apple Mail — \u003Cstrong>requires DMARC at \u003Ccode>quarantine\u003C\u002Fcode> or \u003Ccode>reject\u003C\u002Fcode>\u003C\u002Fstrong>. No DMARC, no logo, no trust signal.\u003C\u002Fli>\n\u003Cli>Phishing using your domain damages your sender reputation even if \u003Cem>you\u003C\u002Fem> never sent the message. DMARC enforcement is the only thing that stops attackers from spoofing your brand.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This is also where your provider choice matters. Configuring SPF, DKIM, and DMARC correctly across multiple vendors is genuinely hard. A platform built for transactional email should hand you copy-paste DNS records, run on lookup-efficient infrastructure, and verify alignment for you — so authentication is a one-time setup, not an ongoing operations burden.\u003C\u002Fp>\n\u003Ch2>Frequently Asked Questions\u003C\u002Fh2>\n\u003Ch3>Do I need all three of SPF, DKIM, and DMARC?\u003C\u002Fh3>\n\u003Cp>Yes. SPF and DKIM each authenticate one aspect of an email, and each has gaps (SPF breaks on forwarding; DKIM doesn't say what to do on failure). DMARC ties them together, enforces alignment, and gives you reporting. Modern mailbox providers like Gmail and Yahoo now \u003Cem>require\u003C\u002Fem> all three for reliable delivery.\u003C\u002Fp>\n\u003Ch3>What's the difference between SPF and DKIM?\u003C\u002Fh3>\n\u003Cp>SPF authorizes which \u003Cstrong>servers\u002FIPs\u003C\u002Fstrong> can send for your domain by checking the connecting IP against a DNS list. DKIM cryptographically \u003Cstrong>signs the message content\u003C\u002Fstrong> so receivers can verify it wasn't altered and genuinely came from your domain. SPF checks the connection; DKIM checks the message. DKIM survives forwarding, SPF does not.\u003C\u002Fp>\n\u003Ch3>What happens if I don't set up email authentication?\u003C\u002Fh3>\n\u003Cp>Your transactional emails are far more likely to land in spam or be rejected outright — especially at Gmail, Yahoo, and Outlook, which now enforce authentication for senders. You also leave your domain open to spoofing and phishing, which harms your brand and sender reputation. Without DMARC, you can't display a verified logo (BIMI) either.\u003C\u002Fp>\n\u003Ch3>How long does it take for SPF, DKIM, and DMARC to work?\u003C\u002Fh3>\n\u003Cp>The DNS records themselves take effect after propagation — usually minutes to a few hours depending on your TTL. The \u003Cem>full rollout\u003C\u002Fem> to \u003Ccode>p=reject\u003C\u002Fcode>, however, should take a few weeks, because you need to read DMARC reports and confirm all legitimate senders pass before enforcing a strict policy.\u003C\u002Fp>\n\u003Ch3>Can SPF, DKIM, and DMARC stop all spoofing?\u003C\u002Fh3>\n\u003Cp>DMARC at \u003Ccode>p=reject\u003C\u002Fcode> stops spoofing that uses your exact domain in the \u003Ccode>From:\u003C\u002Fcode> header — the most common and damaging type. It cannot stop \u003Cstrong>lookalike domains\u003C\u002Fstrong> (e.g., \u003Ccode>yourdomaiin.com\u003C\u002Fcode>) or display-name spoofing, which require separate brand-protection monitoring. Authentication is necessary but not sufficient on its own.\u003C\u002Fp>\n\u003Ch3>What is a DMARC policy of \u003Ccode>p=none\u003C\u002Fcode>, and is it enough?\u003C\u002Fh3>\n\u003Cp>\u003Ccode>p=none\u003C\u002Fcode> is monitor-only: receivers report on failures but take no action. It's the correct \u003Cem>starting\u003C\u002Fem> point because it lets you see all your sending sources without risking real mail. It is \u003Cstrong>not\u003C\u002Fstrong> sufficient long-term — it offers no protection against spoofing. Your goal is to progress to \u003Ccode>p=quarantine\u003C\u002Fcode> and then \u003Ccode>p=reject\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch3>Why does my email pass SPF but fail DMARC?\u003C\u002Fh3>\n\u003Cp>This is almost always an \u003Cstrong>alignment\u003C\u002Fstrong> problem. DMARC requires the SPF-authenticated \u003Ccode>Return-Path\u003C\u002Fcode> domain to match the visible \u003Ccode>From:\u003C\u002Fcode> domain (relaxed or strict). If your provider sends with their own Return-Path domain instead of yours, SPF passes but doesn't align — so DMARC fails. Using a custom Return-Path on your own domain, or relying on an aligned DKIM signature, fixes it.\u003C\u002Fp>\n\u003Ch3>How many DNS lookups does SPF allow?\u003C\u002Fh3>\n\u003Cp>SPF permits a maximum of \u003Cstrong>10 DNS lookups\u003C\u002Fstrong> per evaluation. Each \u003Ccode>include\u003C\u002Fcode>, \u003Ccode>a\u003C\u002Fcode>, \u003Ccode>mx\u003C\u002Fcode>, \u003Ccode>ptr\u003C\u002Fcode>, and \u003Ccode>redirect\u003C\u002Fcode> mechanism counts toward the limit. Exceeding it produces a \u003Ccode>permerror\u003C\u002Fcode>, which most receivers treat as a failure. Use SPF flattening or consolidate senders to stay within budget.\u003C\u002Fp>\n\u003Ch2>Conclusion\u003C\u002Fh2>\n\u003Cp>Email authentication isn't a checkbox — it's the foundation of transactional email deliverability. \u003Cstrong>SPF\u003C\u002Fstrong> says which servers may send for you, \u003Cstrong>DKIM\u003C\u002Fstrong> proves your messages weren't tampered with, and \u003Cstrong>DMARC\u003C\u002Fstrong> enforces both and tells you who's sending as your domain. Together they're the difference between a password reset that arrives in two seconds and one that vanishes into spam.\u003C\u002Fp>\n\u003Cp>The path is straightforward: inventory your senders, publish a single clean SPF record, enable 2048-bit DKIM signing, and roll DMARC from \u003Ccode>p=none\u003C\u002Fcode> to \u003Ccode>p=reject\u003C\u002Fcode> while reading your reports. The most common failures — multiple SPF records, blown lookup limits, alignment mismatches, and stale keys — are all avoidable once you know what to look for.\u003C\u002Fp>\n\u003Ch2>Send Authenticated Email From Day One With Postwing\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Postwing\u003C\u002Fstrong> is a transactional email platform built for developers and SaaS teams who want authentication done right without the operations overhead. When you add your domain, Postwing generates \u003Cstrong>copy-paste SPF, DKIM, and DMARC records\u003C\u002Fstrong>, runs on lookup-efficient infrastructure that won't blow your SPF budget, and verifies alignment so your mail passes DMARC the first time. Custom Return-Path support keeps SPF aligned to \u003Cem>your\u003C\u002Fem> domain, and 2048-bit DKIM signing is on by default.\u003C\u002Fp>\n\u003Cp>And because Postwing accepts \u003Cstrong>USDC payments on Base\u003C\u002Fstrong>, you can spin up production-grade, fully authenticated transactional email without a credit card or a procurement cycle — just connect your wallet and start sending.\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fpostwing.app\">Start sending authenticated email with Postwing →\u003C\u002Fa>\u003C\u002Fp>","fff171ff-7db6-4819-a366-1de2e7705479","2026-06-24T18:28:18.027039+03:00","2026-07-16T00:01:53.823909+03:00","postwing","How Email Authentication Works (SPF, DKIM, DMARC)","Learn how SPF, DKIM, and DMARC email authentication works, with real DNS records, setup steps, and fixes for the mistakes that send mail to spam.","https:\u002F\u002Fapi.postwing.app\u002Fmedia\u002Fblog\u002Frecord_fff171ff-7db6-4819-a366-1de2e7705479\u002F4f150911-437e-402d-b2af-f6e8df787493.png",true,"2026-07-10T09:00:00+03:00",[16,17],"spf dkim dmarc","email authentication"]