{"id":2016,"date":"2025-11-18T13:53:43","date_gmt":"2025-11-18T10:53:43","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/forwarding-broke-your-spf-dmarc-heres-how-srs-and-arc-save-the-day-without-tears\/"},"modified":"2025-11-18T13:56:01","modified_gmt":"2025-11-18T10:56:01","slug":"forwarding-broke-your-spf-dmarc-heres-how-srs-and-arc-save-the-day-without-tears","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/forwarding-broke-your-spf-dmarc-heres-how-srs-and-arc-save-the-day-without-tears\/","title":{"rendered":"Forwarding Broke Your SPF\/DMARC? Here\u2019s How SRS and ARC Save the Day (Without Tears)"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#The_Day_Forwarding_Made_Me_Spill_My_Coffee\"><span class=\"toc_number toc_depth_1\">1<\/span> The Day Forwarding Made Me Spill My Coffee<\/a><\/li><li><a href=\"#Why_Forwarding_Breaks_SPF_and_DMARC_And_Why_Thats_Not_Your_Fault\"><span class=\"toc_number toc_depth_1\">2<\/span> Why Forwarding Breaks SPF and DMARC (And Why That\u2019s Not Your Fault)<\/a><\/li><li><a href=\"#SRS_The_Little_Return-Path_Rewrite_That_Saves_SPF\"><span class=\"toc_number toc_depth_1\">3<\/span> SRS: The Little Return-Path Rewrite That Saves SPF<\/a><ul><li><a href=\"#When_to_Use_SRS\"><span class=\"toc_number toc_depth_2\">3.1<\/span> When to Use SRS<\/a><\/li><\/ul><\/li><li><a href=\"#ARC_The_Receipt_Book_for_Forwarders_and_Filters\"><span class=\"toc_number toc_depth_1\">4<\/span> ARC: The Receipt Book for Forwarders and Filters<\/a><\/li><li><a href=\"#DMARCs_Role_and_Why_Forwarders_Need_Both_SRS_and_ARC\"><span class=\"toc_number toc_depth_1\">5<\/span> DMARC\u2019s Role and Why Forwarders Need Both SRS and ARC<\/a><\/li><li><a href=\"#Setting_Up_SRS_the_Right_Way\"><span class=\"toc_number toc_depth_1\">6<\/span> Setting Up SRS the Right Way<\/a><ul><li><a href=\"#Postfix_with_postsrsd\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Postfix with postsrsd<\/a><\/li><li><a href=\"#Exims_Built-in_SRS\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Exim\u2019s Built-in SRS<\/a><\/li><li><a href=\"#Other_MTAs_and_Managed_Panels\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Other MTAs and Managed Panels<\/a><\/li><li><a href=\"#DNS_and_SPF_for_SRS\"><span class=\"toc_number toc_depth_2\">6.4<\/span> DNS and SPF for SRS<\/a><\/li><\/ul><\/li><li><a href=\"#ARC_Setup_Without_the_Headache\"><span class=\"toc_number toc_depth_1\">7<\/span> ARC Setup Without the Headache<\/a><ul><li><a href=\"#Option_A_OpenARC\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Option A: OpenARC<\/a><\/li><li><a href=\"#Option_B_Rspamd_as_Your_ARC_Swiss_Army_Knife\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Option B: Rspamd as Your ARC Swiss Army Knife<\/a><\/li><li><a href=\"#ARC_Policies_in_Practice\"><span class=\"toc_number toc_depth_2\">7.3<\/span> ARC Policies in Practice<\/a><\/li><\/ul><\/li><li><a href=\"#Putting_It_Together_A_Clean_Forwarding_Flow\"><span class=\"toc_number toc_depth_1\">8<\/span> Putting It Together: A Clean Forwarding Flow<\/a><\/li><li><a href=\"#Real-World_Testing_The_Little_Ritual_That_Saves_Hours\"><span class=\"toc_number toc_depth_1\">9<\/span> Real-World Testing: The Little Ritual That Saves Hours<\/a><\/li><li><a href=\"#Common_Gotchas_Ive_Learned_the_Hard_Way\"><span class=\"toc_number toc_depth_1\">10<\/span> Common Gotchas I\u2019ve Learned the Hard Way<\/a><ul><li><a href=\"#1_You_forgot_to_authorize_your_SRS_domain_in_SPF\"><span class=\"toc_number toc_depth_2\">10.1<\/span> 1) You forgot to authorize your SRS domain in SPF<\/a><\/li><li><a href=\"#2_DKIM_breaks_because_you_helpfully_changed_things\"><span class=\"toc_number toc_depth_2\">10.2<\/span> 2) DKIM breaks because you \u201chelpfully\u201d changed things<\/a><\/li><li><a href=\"#3_Double-SRS_or_inconsistent_secrets\"><span class=\"toc_number toc_depth_2\">10.3<\/span> 3) Double-SRS or inconsistent secrets<\/a><\/li><li><a href=\"#4_DMARC_alignment_confusion\"><span class=\"toc_number toc_depth_2\">10.4<\/span> 4) DMARC alignment confusion<\/a><\/li><li><a href=\"#5_ARC_without_real_verification_is_just_noise\"><span class=\"toc_number toc_depth_2\">10.5<\/span> 5) ARC without real verification is just noise<\/a><\/li><li><a href=\"#6_Too_many_DNS_lookups_in_SPF\"><span class=\"toc_number toc_depth_2\">10.6<\/span> 6) Too many DNS lookups in SPF<\/a><\/li><li><a href=\"#7_You_forgot_bounce_behavior\"><span class=\"toc_number toc_depth_2\">10.7<\/span> 7) You forgot bounce behavior<\/a><\/li><\/ul><\/li><li><a href=\"#Operational_Tips_That_Make_Life_Easier\"><span class=\"toc_number toc_depth_1\">11<\/span> Operational Tips That Make Life Easier<\/a><\/li><li><a href=\"#A_Quick_Word_on_Reports_and_Visibility\"><span class=\"toc_number toc_depth_1\">12<\/span> A Quick Word on Reports and Visibility<\/a><\/li><li><a href=\"#Mini_Case_Study_The_Alias_That_Wouldnt_Behave\"><span class=\"toc_number toc_depth_1\">13<\/span> Mini Case Study: The Alias That Wouldn\u2019t Behave<\/a><\/li><li><a href=\"#What_Success_Looks_Like_in_Your_Headers\"><span class=\"toc_number toc_depth_1\">14<\/span> What Success Looks Like in Your Headers<\/a><\/li><li><a href=\"#Troubleshooting_Playbook_From_Why_to_Aha\"><span class=\"toc_number toc_depth_1\">15<\/span> Troubleshooting Playbook: From \u201cWhy?\u201d to \u201cAha.\u201d<\/a><\/li><li><a href=\"#External_Resources_Worth_a_Peek\"><span class=\"toc_number toc_depth_1\">16<\/span> External Resources Worth a Peek<\/a><\/li><li><a href=\"#Wrapping_It_Up_Forwarding_Without_the_Friday_Night_Fire_Drill\"><span class=\"toc_number toc_depth_1\">17<\/span> Wrapping It Up: Forwarding Without the Friday Night Fire Drill<\/a><\/li><\/ul><\/div>\n<h2 id=\"section-1\"><span id=\"The_Day_Forwarding_Made_Me_Spill_My_Coffee\">The Day Forwarding Made Me Spill My Coffee<\/span><\/h2>\n<p>Ever had that moment when a perfectly good email vanishes into the void the second it\u2019s forwarded? I remember a Tuesday morning\u2014quiet, coffee still warm\u2014when a client pinged me: \u201cOur invoices aren\u2019t reaching customers when they forward them to Gmail.\u201d Classic. The original message sailed through. But the forwarded one? SPF fail. DMARC fail. Cue the head-scratch.<\/p>\n<p>Here\u2019s the thing with email: it\u2019s very good at pretending to be simple. But under the hood, it\u2019s a tangle of headers, cryptographic signatures, and decades of layered decisions. Forwarding, which feels like a \u201cmeh, just pass it along\u201d move, can absolutely wreck SPF and DMARC alignment if you don\u2019t handle it right. The fix is beautifully boring once you know it: SRS for SPF, ARC for DMARC\u2019s sanity. That\u2019s what we\u2019ll unpack today.<\/p>\n<p>We\u2019ll walk through why forwarding breaks authentication in the first place, how <strong>Sender Rewriting Scheme (SRS)<\/strong> patches SPF, how <strong>Authenticated Received Chain (ARC)<\/strong> helps downstream providers trust your forwarded mail, and how to roll them out in a clean, production-ready way. I\u2019ll share the gotchas, the \u201cask me how I know\u201d mistakes, and how I test end-to-end so you don\u2019t have to guess.<\/p>\n<h2 id=\"section-2\"><span id=\"Why_Forwarding_Breaks_SPF_and_DMARC_And_Why_Thats_Not_Your_Fault\">Why Forwarding Breaks SPF and DMARC (And Why That\u2019s Not Your Fault)<\/span><\/h2>\n<p>Let\u2019s start with the picture in your head. An email is sent from alice@example.com through example.com\u2019s mail server. SPF says: \u201cOnly example.com\u2019s servers may send mail for example.com.\u201d DKIM signs the message body and some headers, and DMARC says: \u201cWhen in doubt, trust alignment with the From domain and what SPF\/DKIM say.\u201d All good so far.<\/p>\n<p>Now Bob receives that message at bob@yourdomain.com, which forwards to Bob\u2019s personal Gmail. Your server becomes the new sender in the eyes of Gmail because you initiate a fresh SMTP transaction to Gmail. SPF checks the IP of the <em>forwarding<\/em> server against the original domain\u2019s SPF policy. Oops. Your server isn\u2019t in example.com\u2019s SPF record, so SPF fails. DKIM might still pass if the body and headers weren\u2019t mangled, but forwarding systems sometimes add footers, subject tags, or rewrap long lines. Suddenly DKIM is shaky too.<\/p>\n<p>DMARC lives on top of SPF\/DKIM. It wants either SPF or DKIM to align with the visible From domain. If SPF fails after forwarding and DKIM gets tweaked, DMARC can tumble like a Jenga tower. That\u2019s when you get non-delivery, quarantines, or the dreaded silent drop.<\/p>\n<p>It\u2019s not that forwarding is wrong; it\u2019s that vanilla forwarding ignores the rules modern authentication expects. We need to make the message carry proof: who handled it, what we verified, and why the next hop should still trust it. Enter SRS and ARC.<\/p>\n<h2 id=\"section-3\"><span id=\"SRS_The_Little_Return-Path_Rewrite_That_Saves_SPF\">SRS: The Little Return-Path Rewrite That Saves SPF<\/span><\/h2>\n<p>Think of SRS like putting a return address sticker on a forwarded package. SPF validates the server that originates the SMTP transaction. When you forward a message, <strong>you<\/strong> are now the origin. Without SRS, you\u2019re claiming to send mail on behalf of the original domain, which their SPF will almost certainly reject. With SRS, your server rewrites the envelope sender (Return-Path) into an address you own and can vouch for.<\/p>\n<p>Practically, an address like <code>mailfrom=alice@example.com<\/code> becomes something like <code>SRS0=HASH=example.com=alice@forward.yourdomain.com<\/code>. The HASH is there so bounces can be safely routed back through your forwarder and eventually to the right sender without being abused. To SPF, the mail is now coming from <strong>your<\/strong> domain\u2019s Return-Path, which you authorize via your SPF record. Suddenly, SPF passes again.<\/p>\n<p>In my experience, SRS is the easiest \u201cwhy didn\u2019t we do this earlier?\u201d fix for forwarding setups. Whether you\u2019re running Postfix, Exim, or something more exotic, there\u2019s a straightforward way to enable SRS and stop fighting SPF failures on forwarded mail.<\/p>\n<h3><span id=\"When_to_Use_SRS\">When to Use SRS<\/span><\/h3>\n<p>Use SRS on any system that forwards mail on behalf of other domains. Catch-all forwarders. Aliases that pipe to a personal mailbox elsewhere. Distribution points that just pass through messages unchanged. If your server is a forwarder in any capacity, SRS should be on your shortlist.<\/p>\n<p>One caveat: don\u2019t double-SRS. If mail passes through multiple forwarders, each with SRS, they should detect existing SRS and avoid nesting it endlessly. Good implementations take care of this, but it\u2019s worth checking in testing.<\/p>\n<h2 id=\"section-4\"><span id=\"ARC_The_Receipt_Book_for_Forwarders_and_Filters\">ARC: The Receipt Book for Forwarders and Filters<\/span><\/h2>\n<p>ARC is like a signed chain of custody for email. It doesn\u2019t rewrite anything. Instead, it records what you verified on the inbound hop\u2014SPF, DKIM, DMARC\u2014and seals that record so downstream providers can decide whether to trust it. When DKIM gets broken by a list footer or subject tweak, and SPF now points at a forwarder, ARC lets the next hop see that, yes, before any changes, the message was legit.<\/p>\n<p>From a policy perspective, DMARC doesn\u2019t \u201ctrust\u201d ARC the same way it trusts SPF\/DKIM alignment, but major receivers use ARC as a significant signal. If you run a gateway that filters or modifies mail, signing with ARC is a kindness to everyone downstream. And if you\u2019re a forwarder, it can be the difference between \u201cweirdly inconsistent deliverability\u201d and \u201cthings just work.\u201d<\/p>\n<p>If you want to dig into the mechanics, you can <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc8617\" rel=\"nofollow noopener\" target=\"_blank\">read the ARC RFC<\/a>, but you don\u2019t need to memorize it. What matters: validate inbound, write down your results, sign that record with an ARC seal, and forward. Think of ARC as the paper trail that says, \u201cWe checked this. Here\u2019s what we found. You can verify that we\u2019re not lying.\u201d<\/p>\n<h2 id=\"section-5\"><span id=\"DMARCs_Role_and_Why_Forwarders_Need_Both_SRS_and_ARC\">DMARC\u2019s Role and Why Forwarders Need Both SRS and ARC<\/span><\/h2>\n<p>DMARC ties the room together. It looks for alignment between the visible From domain and either SPF or DKIM. When you forward, SPF alignment is usually lost\u2014unless you perform SRS. DKIM might survive, but any modifications can break it. ARC shows downstream providers that you verified the message before forwarding, which helps when DKIM is altered in transit. The combo looks like this: SRS fixes SPF by making you the responsible sender for the envelope. ARC preserves the \u201cthis was valid when we got it\u201d breadcrumb trail for DMARC-friendly receivers.<\/p>\n<p>If you want a quick refresher on the policy mindset, the <a href=\"https:\/\/dmarc.org\/overview\/\" rel=\"nofollow noopener\" target=\"_blank\">DMARC overview<\/a> is a solid primer. But here, the order of operations matters. <strong>Do SRS for forwarding first.<\/strong> Then, if you modify mail or you\u2019re a reputational hop that wants to help downstream providers, add ARC. That sequence tends to eliminate the hairiest failures.<\/p>\n<h2 id=\"section-6\"><span id=\"Setting_Up_SRS_the_Right_Way\">Setting Up SRS the Right Way<\/span><\/h2>\n<h3><span id=\"Postfix_with_postsrsd\">Postfix with postsrsd<\/span><\/h3>\n<p>On Postfix, the cleanest path I\u2019ve used is <a href=\"https:\/\/github.com\/roehling\/postsrsd\" rel=\"nofollow noopener\" target=\"_blank\">the postsrsd project<\/a>. It\u2019s a small daemon that handles SRS rewrite and reverse. The 60-second tour:<\/p>\n<p>1) Install postsrsd via your distro or build it. 2) Configure a secret key (for the hash) and set the domain you\u2019ll use for rewritten senders, like <code>srs.yourdomain.com<\/code>. 3) Add a DNS record so that domain resolves to your MTA and is included in your SPF record. 4) In Postfix, set <code>sender_canonical_maps<\/code> and <code>recipient_canonical_maps<\/code> to the postsrsd socket. 5) Reload Postfix and send a test.<\/p>\n<p>What you\u2019re looking for after setup is a rewritten Return-Path that starts with <code>SRS0<\/code> or <code>SRS1<\/code> and includes your chosen domain. On bounces, the reverse mapping should send non-delivery notifications back to the original sender correctly. If you see \u201cSRS failure\u201d on bounces, check that your secret and hashing parameters didn\u2019t change mid-flight and that reverse rewriting is enabled.<\/p>\n<h3><span id=\"Exims_Built-in_SRS\">Exim\u2019s Built-in SRS<\/span><\/h3>\n<p>Exim users have it pretty comfy because SRS support is native. You enable it, set your secret and SRS domain, and wire it into your routers\/transports for outbound forwarding. Pay attention to the order of routers; you want SRS to catch forwarded messages, not local deliveries.<\/p>\n<p>A small Exim gotcha I\u2019ve seen: if you use multiple SRS domains or rotate secrets aggressively without tracking rollovers, bounces can get stuck. Keep a short memory of previous secrets so return traffic during the rotation window still verifies.<\/p>\n<h3><span id=\"Other_MTAs_and_Managed_Panels\">Other MTAs and Managed Panels<\/span><\/h3>\n<p>OpenSMTPD and other MTAs support SRS via external tools or patches. On managed panels like cPanel or DirectAdmin, check whether SRS is available and how it\u2019s toggled for domain forwarders vs. virtual aliases. Sometimes it\u2019s on but not for the delivery path you\u2019re actually using. Test each forwarder path individually\u2014aliases, catch-alls, mailing list outputs\u2014and verify Return-Path rewriting on each.<\/p>\n<h3><span id=\"DNS_and_SPF_for_SRS\">DNS and SPF for SRS<\/span><\/h3>\n<p>Don\u2019t forget the SPF part for your SRS domain. If your SRS rewrite domain is <code>srs.yourdomain.com<\/code>, include the IPs or mechanisms needed so SPF passes for that subdomain. Some operators prefer to use the main domain and keep a clean single SPF policy; others isolate SRS on a subdomain. Either works as long as the envelope sender\u2019s domain authorizes your forwarding MTA.<\/p>\n<h2 id=\"section-7\"><span id=\"ARC_Setup_Without_the_Headache\">ARC Setup Without the Headache<\/span><\/h2>\n<p>ARC isn\u2019t hard if you already understand DKIM. You\u2019ll generate a keypair, publish the public key in DNS under a selector, and run a signer that adds ARC headers. The difference is that ARC carries the results of your inbound authentication checks, so you must reliably verify SPF, DKIM, and DMARC on ingress before you seal and forward.<\/p>\n<h3><span id=\"Option_A_OpenARC\">Option A: OpenARC<\/span><\/h3>\n<p>OpenARC is a sibling project to OpenDKIM. You run it alongside your MTA, typically in milter mode for Postfix or via a similar filter interface for other MTAs. Configure it to:<\/p>\n<p>1) Validate inbound SPF and DKIM (usually via your existing SPF checker and OpenDKIM). 2) Record those results in <code>ARC-Authentication-Results<\/code>. 3) Sign with <code>ARC-Message-Signature<\/code> and <code>ARC-Seal<\/code> using your ARC key. 4) Increment ARC sets properly if the message already has ARC from an upstream hop.<\/p>\n<p>Keep your ARC private keys safe and rotate them like DKIM. And make sure your system clock is accurate; timestamps matter for signature validity.<\/p>\n<h3><span id=\"Option_B_Rspamd_as_Your_ARC_Swiss_Army_Knife\">Option B: Rspamd as Your ARC Swiss Army Knife<\/span><\/h3>\n<p>If you already run Rspamd for filtering, enabling ARC signing and verification is refreshingly simple. Rspamd can verify SPF\/DKIM\/DMARC, produce <code>Authentication-Results<\/code>, and add ARC headers in one place. In my setups, this has been the most reliable way to ensure consistent verification before sealing.<\/p>\n<h3><span id=\"ARC_Policies_in_Practice\">ARC Policies in Practice<\/span><\/h3>\n<p>One mental model helps: you\u2019re not telling the world \u201cwe guarantee this message.\u201d You\u2019re telling the world \u201cwe checked this message when it hit our gateway, and here\u2019s what we observed.\u201d That\u2019s useful when downstream changes break DKIM or when forwarders shuffle headers. Major providers read ARC as a trust signal in the bigger story of your mail flow.<\/p>\n<h2 id=\"section-8\"><span id=\"Putting_It_Together_A_Clean_Forwarding_Flow\">Putting It Together: A Clean Forwarding Flow<\/span><\/h2>\n<p>Here\u2019s a flow that\u2019s served me well when building reliable forwarders:<\/p>\n<p>1) Inbound: Verify SPF, DKIM, and DMARC. Keep a local log of <code>Authentication-Results<\/code>. 2) Decide if you\u2019ll modify the message. If yes (e.g., adding headers, footers, or subject tags), assume DKIM might break. 3) Before relaying, sign ARC to capture your inbound results and the message state you saw. 4) Apply SRS so your envelope sender is aligned with your infrastructure. 5) Relay to the next hop with TLS where possible. If transport security is your thing\u2014and it should be\u2014check out <a href=\"https:\/\/www.dchost.com\/blog\/en\/e%e2%80%91postada-mta%e2%80%91sts-tls%e2%80%91rpt-ve-dane-teslim-edilebilirligi-nasil-tatli-tatli-yukseltirsin\/\">this friendly playbook on MTA\u2011STS, TLS\u2011RPT, and DANE for delivery and security<\/a>.<\/p>\n<p>That\u2019s the core play. Once you settle on it, the weird intermittents start disappearing. Forwarding stops feeling like a coin toss, and your helpdesk stops living in the logs.<\/p>\n<h2 id=\"section-9\"><span id=\"Real-World_Testing_The_Little_Ritual_That_Saves_Hours\">Real-World Testing: The Little Ritual That Saves Hours<\/span><\/h2>\n<p>I always test forwarding in pairs. First, I send a message from a domain with strict DMARC (p=reject), strong DKIM, and a clear SPF. Then I forward it through the system I\u2019m fixing and inspect the headers at the destination.<\/p>\n<p>Here\u2019s what I look for:<\/p>\n<p>1) Return-Path: Is it SRS-rewritten to my domain or chosen SRS subdomain? 2) Authentication-Results at the final destination: Does SPF pass for the SRS domain? If not, fix SPF records or the SRS domain you used. 3) DKIM: If it fails, is that because of expected modifications? If yes, ARC should still tell the story that it passed on my inbound hop. 4) ARC: Are there valid <code>ARC-Seal<\/code> headers? If I\u2019m the only ARC hop, is <code>i=1<\/code>? If I\u2019m in a chain, did I increment properly and include <code>cv=pass<\/code> if the chain validated?<\/p>\n<p>Then I run the reverse: send from a simple domain with p=none to see baseline behavior without policy pressure. This helps isolate configuration vs. policy side effects. I also sample a few receivers\u2014Gmail, Outlook, and a smaller provider\u2014because they each have personality. Some weigh ARC more, some less, but consistent SRS plus solid ARC signing is remarkably steady across the board.<\/p>\n<h2 id=\"section-10\"><span id=\"Common_Gotchas_Ive_Learned_the_Hard_Way\">Common Gotchas I\u2019ve Learned the Hard Way<\/span><\/h2>\n<h3><span id=\"1_You_forgot_to_authorize_your_SRS_domain_in_SPF\">1) You forgot to authorize your SRS domain in SPF<\/span><\/h3>\n<p>The message now claims to be from <code>bounce=SRS0=...@srs.yourdomain.com<\/code>, but your SPF record doesn\u2019t include the MTA IP for that domain. SPF still fails. Fix your SPF policy to include your forwarder\u2019s sending IPs for the SRS domain or use the main domain consistently.<\/p>\n<h3><span id=\"2_DKIM_breaks_because_you_helpfully_changed_things\">2) DKIM breaks because you \u201chelpfully\u201d changed things<\/span><\/h3>\n<p>Mailing list footers, subject tags, and signature rewrites are usual suspects. If you must modify content, ARC is your safety net. It won\u2019t make DKIM pass, but it preserves the fact that it did pass <em>before<\/em> you touched it.<\/p>\n<h3><span id=\"3_Double-SRS_or_inconsistent_secrets\">3) Double-SRS or inconsistent secrets<\/span><\/h3>\n<p>When mail hops through multiple forwarders, make sure your SRS implementation recognizes SRS\u2019d senders and only rewrites when needed. Also, secret rotation is great\u2014until bounces can\u2019t reverse. Keep a short history of secrets so in-flight bounces decode properly.<\/p>\n<h3><span id=\"4_DMARC_alignment_confusion\">4) DMARC alignment confusion<\/span><\/h3>\n<p>Remember, DMARC checks alignment with the visible From domain, not the Return-Path. SRS fixes SPF\u2019s technical pass, but for DMARC alignment to be happy via SPF, your SRS domain must align with the From domain. In forwarding scenarios, that rarely happens, which is why you lean on DKIM (and ARC as your supporting evidence). Don\u2019t chase impossible alignment; aim for stable signals.<\/p>\n<h3><span id=\"5_ARC_without_real_verification_is_just_noise\">5) ARC without real verification is just noise<\/span><\/h3>\n<p>ARC is only helpful if your inbound verification is solid. Make sure you\u2019re doing honest SPF\/DKIM\/DMARC checks and writing accurate <code>Authentication-Results<\/code>. If you sign ARC but your inputs are garbage, you\u2019re signing confusion.<\/p>\n<h3><span id=\"6_Too_many_DNS_lookups_in_SPF\">6) Too many DNS lookups in SPF<\/span><\/h3>\n<p>Forwarders sometimes bulk up SPF with includes and lookups. Keep it lean. SPF has lookup limits, and exceeding them can mean hard fails at the worst moments. Consolidate where you can.<\/p>\n<h3><span id=\"7_You_forgot_bounce_behavior\">7) You forgot bounce behavior<\/span><\/h3>\n<p>Forwarding with SRS should still let bounces find the original sender. Test this. Trigger a non-existent mailbox and watch where the bounce goes. If it lands in a black hole, revisit your SRS reverse mapping.<\/p>\n<h2 id=\"section-11\"><span id=\"Operational_Tips_That_Make_Life_Easier\">Operational Tips That Make Life Easier<\/span><\/h2>\n<p>Rotate DKIM and ARC keys on a sane schedule, and don\u2019t set DNS TTLs so high that rotations take days. Keep NTP in good shape so signatures aren\u2019t timestamp-weird. Log your <code>Authentication-Results<\/code> on ingress; they\u2019re gold when you investigate a single flaky provider.<\/p>\n<p>When rolling out SRS\/ARC in production, consider a gentle ramp. For DMARC, p=none lets you watch aggregate reports and see who fails and why. Once your forwarding is behaving, you can move toward quarantine or reject confidently. If you\u2019re orchestrating broader email reliability and transport security, you might also enjoy how I approach deliverability with MTA\u2011STS and TLS\u2011RPT; it complements the authentication story nicely in practice.<\/p>\n<p>Finally, keep your helpdesk scripts updated. When someone says, \u201cIt works to my work mailbox but not to my Gmail,\u201d your team should immediately think: check SRS rewrite, check ARC presence, inspect final <code>Authentication-Results<\/code>. Ten minutes of habit beats two hours of log archaeology.<\/p>\n<h2 id=\"section-12\"><span id=\"A_Quick_Word_on_Reports_and_Visibility\">A Quick Word on Reports and Visibility<\/span><\/h2>\n<p>DMARC aggregate reports (RUA) are a gift. They tell you how often receivers saw your mail, whether SPF\/DKIM aligned, and what policies were applied. For a forwarder, this can be a little noisy since alignment is not always the goal. But it\u2019s still useful to spot trends, misconfigurations, or a broken SRS domain after a DNS change. Even if you don\u2019t obsess over every report, glance weekly during rollout.<\/p>\n<p>On the ARC side, there\u2019s no centralized \u201creporting\u201d like DMARC. You\u2019ll mostly rely on delivery success, reputation metrics from receivers, and your own logs. That\u2019s fine. ARC\u2019s job is to add context, not to be another dashboard you have to babysit.<\/p>\n<h2 id=\"section-13\"><span id=\"Mini_Case_Study_The_Alias_That_Wouldnt_Behave\">Mini Case Study: The Alias That Wouldn\u2019t Behave<\/span><\/h2>\n<p>A few months ago, a small team had a simple setup: aliases on their domain forwarded to various personal mailboxes. Everything looked fine until a partner tightened DMARC to reject. Suddenly, invoices and support threads vanished when forwarded to Outlook addresses. We enabled SRS on the Postfix host with postsrsd, added the SRS subdomain to SPF, and watched SPF go green at the destination. DKIM still broke occasionally when the CRM added headers on the way out, so we turned on ARC signing in Rspamd. Within a day, delivery stabilized across Gmail and Outlook. No drama. The surprising part wasn\u2019t that it worked\u2014it\u2019s how quickly the mystery disappeared once the right signals were in place.<\/p>\n<h2 id=\"section-14\"><span id=\"What_Success_Looks_Like_in_Your_Headers\">What Success Looks Like in Your Headers<\/span><\/h2>\n<p>When you\u2019re done, your forwarded messages will tell a neat little story:<\/p>\n<p>1) Return-Path shows an SRS address at your domain. 2) Authentication-Results at the destination show SPF pass for that SRS domain. 3) If DKIM broke due to an expected modification, ARC headers reflect that it passed when you received it. 4) If DKIM didn\u2019t break, even better; DMARC will be happy via DKIM alignment, and ARC is just an extra breadcrumb for later hops.<\/p>\n<p>That\u2019s the signature of a clean forwarding pipeline: nothing fancy, just consistent signals.<\/p>\n<h2 id=\"section-15\"><span id=\"Troubleshooting_Playbook_From_Why_to_Aha\">Troubleshooting Playbook: From \u201cWhy?\u201d to \u201cAha.\u201d<\/span><\/h2>\n<p>When something still misbehaves, I run this dance:<\/p>\n<p>1) Inspect headers at the final mailbox. Find <code>Authentication-Results<\/code>, <code>ARC-Authentication-Results<\/code>, and <code>Received-SPF<\/code>. 2) Confirm whether SPF failed due to using the original sender\u2019s domain. If yes, SRS didn\u2019t trigger or SPF for your SRS domain is wrong. 3) If DKIM failed, compare the body hash to see if a footer or tag caused it. If that\u2019s expected, ARC should still communicate the ground truth from your ingress hop. 4) Look for multiple ARC sets. If there are more than one, make sure yours is the most recent and valid. 5) Check DNS for your ARC\/DKIM selectors and SRS domain. Typos and stale keys love to ruin afternoons. 6) Finally, send a minimal, plain-text message through the same path. If that passes cleanly, content modifications are the culprit; not the pipeline.<\/p>\n<h2 id=\"section-16\"><span id=\"External_Resources_Worth_a_Peek\">External Resources Worth a Peek<\/span><\/h2>\n<p>If you like reading specs or want a deeper dive later, I\u2019ve found these handy to keep bookmarked:<\/p>\n<p>&#8211; The <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc8617\" rel=\"nofollow noopener\" target=\"_blank\">ARC RFC (RFC 8617)<\/a> for the formal model and header formats. &#8211; The <a href=\"https:\/\/dmarc.org\/overview\/\" rel=\"nofollow noopener\" target=\"_blank\">DMARC overview<\/a> for a crisp policy refresher. &#8211; The <a href=\"https:\/\/github.com\/roehling\/postsrsd\" rel=\"nofollow noopener\" target=\"_blank\">postsrsd project<\/a> for a battle-tested Postfix SRS implementation.<\/p>\n<h2 id=\"section-17\"><span id=\"Wrapping_It_Up_Forwarding_Without_the_Friday_Night_Fire_Drill\">Wrapping It Up: Forwarding Without the Friday Night Fire Drill<\/span><\/h2>\n<p>Forwarding doesn\u2019t have to be a gamble. The moment you accept that SPF evaluates the current sending server\u2014and that forwarding changes who that is\u2014SRS becomes an obvious fix. You rewrite the envelope sender into a domain you control, SPF passes, and bounces still find their way home. Then you add ARC when you want to preserve a trustworthy record of what was true on ingress, especially if you or someone downstream might touch the message in a way that breaks DKIM. That\u2019s the whole play.<\/p>\n<p>If you\u2019re rolling this out, tackle it step by step: enable SRS on the forwarder and confirm SPF passes at the destination. Then enable ARC signing only after you\u2019re reliably verifying inbound SPF\/DKIM\/DMARC. Test with a strict DMARC sender and a relaxed one. Read the headers like a story. They always tell you what happened if you know where to look.<\/p>\n<p>And hey, if you\u2019re also polishing the rest of your mail pipeline, tightening transport with MTA\u2011STS and friends makes a nice companion project. Either way, I hope this clears the fog around forwarding, SPF, DMARC, SRS, and ARC. Set it up once, test it well, and get your Friday nights back. Hope this was helpful! See you in the next post, and may your headers always make sense.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>\u0130&ccedil;indekiler1 The Day Forwarding Made Me Spill My Coffee2 Why Forwarding Breaks SPF and DMARC (And Why That\u2019s Not Your Fault)3 SRS: The Little Return-Path Rewrite That Saves SPF3.1 When to Use SRS4 ARC: The Receipt Book for Forwarders and Filters5 DMARC\u2019s Role and Why Forwarders Need Both SRS and ARC6 Setting Up SRS the [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":2017,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[184,26],"tags":[],"class_list":["post-2016","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2016","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=2016"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2016\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/2017"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=2016"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=2016"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=2016"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}