{"id":700,"date":"2026-04-09T20:47:50","date_gmt":"2026-04-09T20:47:50","guid":{"rendered":"https:\/\/blog.asambe.ai\/index.php\/2026\/04\/09\/implement-spf-dkim-dmarc-a-step-by-step-guide\/"},"modified":"2026-04-09T20:47:53","modified_gmt":"2026-04-09T20:47:53","slug":"implement-spf-dkim-dmarc-a-step-by-step-guide","status":"publish","type":"post","link":"https:\/\/blog.asambe.ai\/index.php\/2026\/04\/09\/implement-spf-dkim-dmarc-a-step-by-step-guide\/","title":{"rendered":"Implement SPF DKIM DMARC A Step-by-Step Guide"},"content":{"rendered":"<p>Email is the backbone of modern business communication, yet it remains a prime target for spoofing and phishing. If your domain lacks proper authentication, bad actors can impersonate you, customers may stop trusting your messages, and inbox providers will send more of your emails to spam. The good news: with SPF, DKIM, and DMARC, you can move from zero to protected in a structured, low-risk way.<\/p>\n<p>This guide walks you through what these standards are, why they matter, and exactly how to implement them. Whether you run a small business or manage a large brand, you will learn a practical, step-by-step path to authenticate your mail, improve deliverability, and protect your domain\u2019s reputation.<\/p>\n<h2 id=\"table-of-contents\">Table of Contents<\/h2>\n<ul>\n<li><a href=\"#what-are-spf-dkim-dmarc\">What Are SPF, DKIM &amp; DMARC?<\/a><\/li>\n<li><a href=\"#how-authentication-works\">How Email Authentication Works Together<\/a><\/li>\n<li><a href=\"#prerequisites-planning\">Prerequisites and Planning<\/a><\/li>\n<li><a href=\"#implement-spf\">Step 1: Implement SPF<\/a><\/li>\n<li><a href=\"#implement-dkim\">Step 2: Implement DKIM<\/a><\/li>\n<li><a href=\"#implement-dmarc\">Step 3: Implement DMARC<\/a><\/li>\n<li><a href=\"#monitoring-reporting\">Monitoring, Reporting, and Iteration<\/a><\/li>\n<li><a href=\"#advanced-tips\">Advanced Tips: Alignment, Subdomains, BIMI<\/a><\/li>\n<li><a href=\"#troubleshooting-pitfalls\">Troubleshooting and Common Pitfalls<\/a><\/li>\n<li><a href=\"#conclusion\">Conclusion<\/a><\/li>\n<li><a href=\"#frequently-asked-questions\">Frequently Asked Questions<\/a><\/li>\n<\/ul>\n<h2 id=\"what-are-spf-dkim-dmarc\">What Are SPF, DKIM &amp; DMARC?<\/h2>\n<p>SPF, DKIM, and DMARC are open standards that prove your email really comes from your domain and has not been tampered with. Together, they help mailbox providers decide whether to trust and deliver your messages.<\/p>\n<ul>\n<li><strong>SPF (Sender Policy Framework):<\/strong> A DNS record listing the servers allowed to send mail for your domain. Receivers check the sending IP against your list.<\/li>\n<li><strong>DKIM (DomainKeys Identified Mail):<\/strong> Cryptographically signs messages with a private key. Receivers use your public key in DNS to verify that the message wasn\u2019t altered and is associated with your domain.<\/li>\n<li><strong>DMARC (Domain-based Message Authentication, Reporting &amp; Conformance):<\/strong> A policy that tells receivers how to treat messages that fail SPF\/DKIM checks, and sends you reports so you can monitor abuse and fix misconfigurations. Crucially, DMARC requires <em>alignment<\/em> between authenticated domains and the visible From: domain.<\/li>\n<\/ul>\n<h2 id=\"how-authentication-works\">How Email Authentication Works Together<\/h2>\n<p>Think of SPF and DKIM as your proof sources, and DMARC as the rulebook that interprets those proofs:<\/p>\n<ol>\n<li><strong>SPF<\/strong> checks the path your email took (the sending server) against your DNS record.<\/li>\n<li><strong>DKIM<\/strong> checks the integrity of the message using a digital signature attached to the email headers.<\/li>\n<li><strong>DMARC<\/strong> compares the domain in the visible From: address to the domains authenticated by SPF or DKIM. If either SPF or DKIM passes <em>and<\/em> is aligned, DMARC passes. If not, receivers apply your DMARC policy.<\/li>\n<\/ol>\n<p>Alignment means the domain that passed SPF or DKIM matches (or is a subdomain of) the visible From: domain. This stops attackers from passing SPF\/DKIM with unrelated domains while spoofing your brand in the From: line.<\/p>\n<h2 id=\"prerequisites-planning\">Prerequisites and Planning<\/h2>\n<p>Before you edit DNS, gather the following:<\/p>\n<ul>\n<li><strong>Complete list of senders:<\/strong> All services that send on your behalf (e.g., your mailbox provider, CRM, marketing platform, help desk, billing, web app, server alerts).<\/li>\n<li><strong>DNS access:<\/strong> Logins to your domain\u2019s DNS host (registrar or DNS provider).<\/li>\n<li><strong>Reporting inboxes:<\/strong> Create dedicated addresses for DMARC reports, e.g., <em>dmarc-aggregate@example.com<\/em> (for <strong>rua<\/strong>) and optionally <em>dmarc-forensic@example.com<\/em> (for <strong>ruf<\/strong>).<\/li>\n<li><strong>Change window:<\/strong> Plan updates during low-traffic times and set conservative TTLs (e.g., 1 hour) while you iterate.<\/li>\n<\/ul>\n<p>Implementation strategy: start with SPF and DKIM for every sender, then roll out DMARC in stages (monitoring, quarantine, reject). This minimizes risk while you gain visibility.<\/p>\n<h2 id=\"implement-spf\">Step 1: Implement SPF<\/h2>\n<h3>How SPF works<\/h3>\n<p>SPF lists authorized sending sources for your domain. Receivers compare the connecting IP or include mechanism to your record, then calculate a pass, softfail, or fail.<\/p>\n<h3>What to publish<\/h3>\n<ul>\n<li>Create or update a single TXT record at the root of your domain (<em>example.com<\/em>):<\/li>\n<\/ul>\n<p><strong>Example SPF record:<\/strong> <em>example.com<\/em> TXT &#8220;v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all&#8221;<\/p>\n<ul>\n<li><strong>Mechanisms:<\/strong> <em>ip4\/ip6<\/em> (direct IPs), <em>include:<\/em> (third-party senders), <em>a<\/em>\/<em>mx<\/em> (only if those hosts send), <em>all<\/em> (default action).<\/li>\n<li><strong>Start with<\/strong> <em>~all<\/em> (softfail) while auditing. Move to <em>-all<\/em> (hard fail) once confident.<\/li>\n<li><strong>Combine into one record:<\/strong> You must have exactly one SPF TXT record at the root. Multiple SPF records cause failures.<\/li>\n<li><strong>Respect the 10-lookup limit:<\/strong> Each <em>include:<\/em> and some mechanisms count toward this. Use vendor \u201c*_spf\u201d includes and flatten only with care.<\/li>\n<\/ul>\n<h3>Steps<\/h3>\n<ol>\n<li>List all senders and find each provider\u2019s SPF include.<\/li>\n<li>Publish one consolidated SPF record. Set TTL to 3600s (1 hour) initially.<\/li>\n<li>Send test emails from each system and check headers for <em>Received-SPF: pass<\/em>.<\/li>\n<li>After validation, consider switching <em>~all<\/em> to <em>-all<\/em> for stricter enforcement.<\/li>\n<\/ol>\n<h2 id=\"implement-dkim\">Step 2: Implement DKIM<\/h2>\n<h3>How DKIM works<\/h3>\n<p>DKIM signs messages with a private key at send time. Receivers fetch your public key from a DNS TXT record named <em>selector._domainkey.example.com<\/em> and verify the signature.<\/p>\n<h3>What to publish<\/h3>\n<ul>\n<li>Generate keys in each sending platform (e.g., your mailbox provider and any bulk sender). Use 2048-bit keys if supported.<\/li>\n<li>Publish the provided selector TXT records in DNS.<\/li>\n<li>Enable signing for your domain in the provider\u2019s console.<\/li>\n<\/ul>\n<p><strong>Example DKIM record:<\/strong> <em>s1._domainkey.example.com<\/em> TXT &#8220;v=DKIM1; k=rsa; p=MIIBIjANBgkqh&#8230;AB&#8221;<\/p>\n<h3>Best practices<\/h3>\n<ul>\n<li><strong>Use unique selectors per platform<\/strong> (e.g., <em>s1<\/em> for your mailbox, <em>mktg1<\/em> for marketing) so you can rotate keys independently.<\/li>\n<li><strong>Rotate keys periodically<\/strong> (e.g., every 6\u201312 months). Create a new selector, publish, switch traffic, then retire the old one.<\/li>\n<li><strong>Verify signatures<\/strong> by sending test messages to external mailboxes and checking headers for <em>DKIM-Signature<\/em> and <em>Authentication-Results<\/em> with <em>dkim=pass<\/em>.<\/li>\n<\/ul>\n<h2 id=\"implement-dmarc\">Step 3: Implement DMARC<\/h2>\n<h3>Start in monitor mode<\/h3>\n<p>DMARC tells receivers what to do when SPF\/DKIM fail to align with your From: domain and where to send reports. Begin with <em>p=none<\/em> to gather data without impacting delivery.<\/p>\n<p><strong>Initial DMARC record:<\/strong> <em>_dmarc.example.com<\/em> TXT &#8220;v=DMARC1; p=none; rua=mailto:dmarc-aggregate@example.com; fo=1; adkim=s; aspf=s; pct=100&#8221;<\/p>\n<ul>\n<li><strong>rua:<\/strong> Aggregate reports (XML) from providers. Route these to a parser or SIEM.<\/li>\n<li><strong>ruf (optional):<\/strong> Forensic\/failure samples. Consider privacy and volume before enabling.<\/li>\n<li><strong>adkim\/aspf:<\/strong> Set <em>=s<\/em> (strict) for tighter alignment or <em>=r<\/em> (relaxed) to allow subdomains. Start with <em>s<\/em> if practical for stronger protection.<\/li>\n<li><strong>pct:<\/strong> Percentage of messages the policy applies to. Useful when ramping to quarantine\/reject.<\/li>\n<\/ul>\n<h3>Move to enforcement<\/h3>\n<ol>\n<li><strong>30\u201360 days in monitor mode:<\/strong> Review reports to confirm all legitimate sources pass and align.<\/li>\n<li><strong>Quarantine phase:<\/strong> Change to <em>p=quarantine<\/em>; optionally set <em>pct=25<\/em>, then 50, 75, 100.<\/li>\n<li><strong>Reject phase:<\/strong> Change to <em>p=reject<\/em> when confident. This is the strongest protection against spoofing.<\/li>\n<\/ol>\n<p><strong>Enforcement example:<\/strong> <em>_dmarc.example.com<\/em> TXT &#8220;v=DMARC1; p=reject; rua=mailto:dmarc-aggregate@example.com; adkim=s; aspf=s; sp=quarantine&#8221;<\/p>\n<p><em>sp<\/em> sets a policy for subdomains (e.g., <em>mail.example.com<\/em>) if you want different handling than the root domain.<\/p>\n<h2 id=\"monitoring-reporting\">Monitoring, Reporting, and Iteration<\/h2>\n<h3>Reading DMARC reports<\/h3>\n<p>Aggregate reports summarize who is sending mail on your behalf, where it originates, and whether SPF\/DKIM passed with alignment. Use a DMARC report analyzer to translate XML into dashboards and trends.<\/p>\n<ul>\n<li><strong>Watch for unknown sources:<\/strong> New IPs, services, or countries may indicate abuse or misconfiguration.<\/li>\n<li><strong>Track pass rates over time:<\/strong> Aim for near-100% SPF or DKIM alignment passes on legitimate mail before enforcement.<\/li>\n<li><strong>Correlate with deliverability metrics:<\/strong> Monitor open rates, bounce codes, spam complaints, and blocklists as you tighten policy.<\/li>\n<\/ul>\n<h3>Iterate continuously<\/h3>\n<ul>\n<li>Add or remove senders in SPF and DKIM as your stack changes.<\/li>\n<li>Rotate DKIM keys on a schedule.<\/li>\n<li>Periodically re-validate alignment after platform updates or domain changes.<\/li>\n<\/ul>\n<h2 id=\"advanced-tips\">Advanced Tips: Alignment, Subdomains, BIMI<\/h2>\n<h3>Alignment nuances<\/h3>\n<ul>\n<li><strong>SPF alignment<\/strong> is based on the <em>Return-Path<\/em> (also called the envelope from). Make sure it uses the same domain as the visible From: domain or a subdomain if relaxed alignment is allowed.<\/li>\n<li><strong>DKIM alignment<\/strong> uses the <em>d=<\/em> domain in the DKIM signature. Configure each sender to sign with your domain, not the vendor\u2019s default domain, to achieve alignment.<\/li>\n<\/ul>\n<h3>Subdomains and multi-domain environments<\/h3>\n<ul>\n<li>Use <strong>sp=<\/strong> in DMARC to set a separate policy for subdomains (e.g., testing on <em>dev.example.com<\/em> while enforcing on <em>example.com<\/em>).<\/li>\n<li>In large organizations, consider a central policy at the organizational domain and explicit policies for high-volume subdomains.<\/li>\n<\/ul>\n<h3>BIMI prerequisites<\/h3>\n<p>Brand Indicators for Message Identification (BIMI) can display your logo in supported inboxes. It requires strong authentication (DMARC at <em>quarantine<\/em> or <em>reject<\/em>), a published SVG logo, and often a Verified Mark Certificate (VMC). BIMI does not improve deliverability by itself, but it can increase brand trust and recognition once you reach enforcement.<\/p>\n<h2 id=\"troubleshooting-pitfalls\">Troubleshooting and Common Pitfalls<\/h2>\n<ul>\n<li><strong>Multiple SPF records:<\/strong> Merge them into one. Example: combine provider includes into a single <em>v=spf1 &#8230; -all<\/em> record.<\/li>\n<li><strong>SPF 10-lookup limit exceeded:<\/strong> Use vendor-provided consolidated includes, remove unnecessary mechanisms (<em>a<\/em>, <em>mx<\/em>), and avoid nested includes where possible.<\/li>\n<li><strong>Forwarding breaks SPF:<\/strong> Forwarders can change the sending IP, causing SPF to fail. DMARC can still pass via DKIM, so ensure strong DKIM signing on all mail.<\/li>\n<li><strong>Misaligned From: domain:<\/strong> Some platforms sign with <em>vendor.com<\/em> by default. Change settings to sign with <em>yourdomain.com<\/em> and set a custom Return-Path if supported.<\/li>\n<li><strong>Old DKIM selectors lingering:<\/strong> Remove unused public keys from DNS to reduce attack surface.<\/li>\n<li><strong>Typos in TXT records:<\/strong> Extra spaces, missing semicolons, or incorrect quotes can invalidate records. Validate syntax with reputable DNS or DMARC testing tools.<\/li>\n<li><strong>Ignoring reports:<\/strong> DMARC\u2019s power is in visibility. Review and act on reports regularly, especially after onboarding new sending services.<\/li>\n<\/ul>\n<h2 id=\"conclusion\">Conclusion<\/h2>\n<p>By authenticating with SPF and DKIM and enforcing with DMARC, you protect your brand, increase inbox placement, and gain control over who can send using your domain. Start small: catalog senders, publish a clean SPF, enable DKIM across all platforms, and roll out DMARC in stages from <em>p=none<\/em> to <em>p=reject<\/em>. With ongoing monitoring and occasional tuning, you can keep your domain locked down while maintaining excellent deliverability.<\/p>\n<p><strong>Next steps:<\/strong> Implement SPF and DKIM today, publish a DMARC record in monitor mode, and set a calendar reminder to review reports in 2\u20134 weeks. From there, ramp to enforcement confidently.<\/p>\n<h2 id=\"frequently-asked-questions\">Frequently Asked Questions<\/h2>\n<p><strong>How long do DNS changes take to propagate?<\/strong><\/p>\n<p>Most changes are visible within minutes, but full propagation can take up to 24\u201348 hours depending on TTLs and resolver caching. Plan changes accordingly.<\/p>\n<p><strong>Do I need all three: SPF, DKIM, and DMARC?<\/strong><\/p>\n<p>Yes. SPF and DKIM provide the technical proof, while DMARC enforces alignment and gives you reporting. Skipping any piece reduces protection and visibility.<\/p>\n<p><strong>We use multiple email services. Is that a problem?<\/strong><\/p>\n<p>No. Add each provider to SPF and enable DKIM per platform with your domain. DMARC reports will confirm everything is aligned and passing.<\/p>\n<p><strong>What if I can\u2019t move to p=reject right away?<\/strong><\/p>\n<p>Use <em>p=quarantine<\/em> and\/or <em>pct<\/em> to phase in enforcement. Many organizations remain at quarantine for a period before advancing to reject.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Learn how to implement SPF, DKIM, and DMARC for your domain. Step-by-step DNS setup, testing, and best practices to boost deliverability and stop spoofing.<\/p>\n","protected":false},"author":1,"featured_media":699,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_hide_featured_image":false,"_jetpack_featured_image_duplicate_dismissed":0,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[8],"tags":[],"class_list":["post-700","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-posts"],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/i0.wp.com\/blog.asambe.ai\/wp-content\/uploads\/2026\/04\/2026-04-09-20-47-42-data.png?fit=1024%2C1024&ssl=1","_links":{"self":[{"href":"https:\/\/blog.asambe.ai\/index.php\/wp-json\/wp\/v2\/posts\/700","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.asambe.ai\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.asambe.ai\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.asambe.ai\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.asambe.ai\/index.php\/wp-json\/wp\/v2\/comments?post=700"}],"version-history":[{"count":1,"href":"https:\/\/blog.asambe.ai\/index.php\/wp-json\/wp\/v2\/posts\/700\/revisions"}],"predecessor-version":[{"id":701,"href":"https:\/\/blog.asambe.ai\/index.php\/wp-json\/wp\/v2\/posts\/700\/revisions\/701"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.asambe.ai\/index.php\/wp-json\/wp\/v2\/media\/699"}],"wp:attachment":[{"href":"https:\/\/blog.asambe.ai\/index.php\/wp-json\/wp\/v2\/media?parent=700"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.asambe.ai\/index.php\/wp-json\/wp\/v2\/categories?post=700"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.asambe.ai\/index.php\/wp-json\/wp\/v2\/tags?post=700"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}