A thing that trips people up constantly, and the numbers behind it are worth having in one place. 𝟰𝘅𝘅 𝗶𝘀 𝗻𝗼𝘁 𝗮 𝗯𝗼𝘂𝗻𝗰𝗲. 𝗜𝘁 𝗶𝘀 𝗮 𝗱𝗲𝗹𝗮𝘆. The receiving server is saying try again later, and RFC 5321 section 4.2.1 is explicit that the client should. Mailbox full, greylisting, rate limit, transient DNS trouble. 𝟱𝘅𝘅 𝗶𝘀 𝗳𝗶𝗻𝗮𝗹. Same section: the client must not try again to the same recipient. So when a platform reports a soft bounce, nothing has failed yet. A queue has opened. How long that queue stays open is where it gets interesting, because it is a local decision and not a standard. 𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗲𝗱 𝗱𝗲𝗳𝗮𝘂𝗹𝘁𝘀:

• 𝗣𝗼𝘀𝘁𝗳𝗶𝘅: maximal_queue_lifetime defaults to 𝟱𝗱. Retry interval runs from minimal_backoff_time 300s to maximal_backoff_time 4000s.
• 𝗔𝗺𝗮𝘇𝗼𝗻 𝗦𝗘𝗦: 𝟭𝟰 𝗵𝗼𝘂𝗿𝘀 by default, configurable from 300 to 50,400 seconds since October 2024.
• 𝗚𝗺𝗮𝗶𝗹: no published retry window at all. That last one deserves a note. The 45 hours figure that circulates comes from DSN message bodies quoted in forums, not from any Google documentation. I went looking properly and it is not there. If someone has an actual documented source I would genuinely like to see it. The 5 day Postfix default is not arbitrary either. RFC 1123 section 5.3.1.1, which RFC 5321 inherits, says the give up time generally needs to be at least four to five days. Practical consequence: the same address gets an 8.5x difference in second chances depending on what is sending. If you suppress on first soft bounce you are throwing away deliverable addresses on one stack and not the other. What is your queue lifetime set to, and did you choose it or inherit the default?

Posting this because I only found out this week and I suspect I am not alone. 𝗥𝗙𝗖 𝟵𝟵𝟴𝟵, Standards Track, published May 2026. The header line reads 𝗢𝗯𝘀𝗼𝗹𝗲𝘁𝗲𝘀: 𝟳𝟰𝟴𝟵, 𝟵𝟬𝟵𝟭. RFC 7489 is the document that essentially every DMARC guide, tutorial and vendor doc has cited since 2015. It has been historical for three months. 𝗪𝗵𝗮𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗰𝗵𝗮𝗻𝗴𝗲𝗱, 𝘄𝗵𝗶𝗰𝗵 𝗶𝘀 𝗹𝗲𝘀𝘀 𝘁𝗵𝗮𝗻 𝘆𝗼𝘂 𝘄𝗼𝘂𝗹𝗱 𝗲𝘅𝗽𝗲𝗰𝘁: Identifier alignment was section 3.1 in 7489. It is 𝘀𝗲𝗰𝘁𝗶𝗼𝗻 𝟯.𝟮.𝟭𝟬 in 9989. The definitions survived intact: relaxed alignment means the Author Domain shares an Organizational Domain with an authenticated identifier, strict means they are identical. So if your runbook or your internal wiki links to 7489 section 3.1, the section number is wrong and the concept is fine. That is the whole migration for most people. 𝗧𝗵𝗲 𝗽𝗮𝗿𝘁 𝘄𝗼𝗿𝘁𝗵 𝗿𝗲𝗿𝗲𝗮𝗱𝗶𝗻𝗴 𝗿𝗲𝗴𝗮𝗿𝗱𝗹𝗲𝘀𝘀: SPF can pass while DMARC fails, and this is not a bug or a misconfiguration. A forwarder that rewrites the return path makes SPF pass, but it passes for the forwarder's domain, which no longer shares an Organizational Domain with the From header. Alignment fails, so DMARC fails, on a message that authenticated perfectly. DKIM survives forwarding and SPF does not, because DKIM is a cryptographic property of the message while SPF is a property of the connecting IP. One caveat stated plainly: no RFC writes that in a single sentence. It is a derivation from the alignment definition plus RFC 7960 on interoperability. I would rather say that than pretend I found a quote. Links: RFC 9989 https://dub.sh/qIpjYgm RFC 7960 https://dub.sh/iioNfqn Has anyone here already migrated their internal documentation, or is everyone still pointing at 7489? https://dub.sh/zkBKfMr