[{"content":"I have previously explained the important part permission can play in successful mail programs. But what if you intend to send messages to people who never gave you any level of permission to do so? You may feel entitled to send these messages because they have a veneer of legitimacy such as implied consent or legal permissibility. But is is really a good idea?\nImplied consent Implied consent is when you collect an email address but fail to also collect explicit permission use it for marketing purposes. Sometimes that\u0026rsquo;s fine because the address was surrendered with an assumption that that it would be used for marketing. Sometimes it\u0026rsquo;s not fine because no such assumption was made. How do you know the difference without waiting for complaints? Get any contacts with implied consent properly permissioned before you start sending marketing messages to them. Reluctance to take this step is proof of how weak you know the implied part really is.\nMandated sends Mandated sends cover regulatory and product recall type notifications. These are messages you are legally required to send and sometimes the scope may include former customers, people who have unsubscribed, etc. These sends can generate a lot of bounces and complaints. While you are legally required to send these messages you should take steps to mitigate the risk of damaging your sender reputation. Talk to your ESP and follow their advise. Push back on any requests to attach a PDF and if you must do, follow the advice I covered in this post.\nSales emails By their nature most sales emails are unsolicited. Regardless of legality many people consider all unsolicited sales messages to be spam and vote them out of the inbox. This is understandable since most organizations use spammer math when sending sales messages. On the other hand some businesses can make a data-driven argument that sales emails are their top source of qualified leads and contribute to growth. There is a paper thin line between sending relevant emails to properly targeted prospects and outright spamming. Tread carefully.\nRemember, sometimes the only way to win is not to play send.\n","permalink":"https://emaildeliverabilityexplained.com/posts/2026/08/sending-without-permission/","summary":"\u003cp\u003eI have \u003ca href=\"/posts/2026/08/why-permission-is-important/\"\n  \n  \n\u003epreviously explained\u003c/a\u003e the important part permission can play in successful mail programs. But what if you intend to send messages to people who never gave you any level of permission to do so? You may feel entitled to send these messages because they have a veneer of legitimacy such as implied consent or legal permissibility. But is is really a good idea?\u003c/p\u003e\n\u003ch4 id=\"implied-consent\"\u003eImplied consent\u003c/h4\u003e\n\u003cp\u003eImplied consent is when you collect an email address but fail to also collect explicit permission use it for marketing purposes. Sometimes that\u0026rsquo;s fine because the address was surrendered with an assumption that that it would be used for marketing. Sometimes it\u0026rsquo;s not fine because no such assumption was made. How do you know the difference without waiting for complaints?  Get any contacts with implied consent properly permissioned before you start sending marketing messages to them. Reluctance to take this step is proof of how weak you know the \u003cem\u003eimplied\u003c/em\u003e part really is.\u003c/p\u003e","title":"Sending Without Permission"},{"content":"Spammer math is basically any variation of the following line of reasoning: if I get one sale from a send to one thousand messages that means that I will get one hundred sales sending to one hundred thousand messages and so on until infinity. It can be expressed as (s=cm) where s is sales, c is the conversation rate, and m is the number of messages sent.\nThis model is based on the idea that sales will scale at a constant multiplier relative to messages sent. The foil here is probability. The assumption is that each message sent has the exact same independent probability of converting. This is false because as the number of messages increases so too does the probability of bounces and complaints, which increases the probability of sender reputation problems which in turn causes the probability of conversions to increasingly diminish. In economics this is often referred to as the law of diminishing returns.\nThe model requires ever increasing volumes of fresh email addresses to make the math work. Only low-quality data sources can provide the volumes needed, which in turn sabotage deliverability, requiring more new contacts\u0026hellip;\nYou don\u0026rsquo;t have to be pumping penny stocks to get sucked into this fallacy. Legitimate organizations can also fall down this rabbit hole simply because they don’t know better or are badly advised.\nSenders will try to beat the fallacy by using multiple domains and sending sources. This doesn\u0026rsquo;t change the math or the outcomes and just digs the hole deeper and deeper.\nSpammer math doesn’t work and the hint’s in the name. Just because you may hit the occasional diamond in the rough doesn’t mean it‘s a viable or sustainable strategy for any sender.\nThe solution - have a proper strategy for scaling the growth of your email program.\n","permalink":"https://emaildeliverabilityexplained.com/posts/2026/08/spammer-math/","summary":"\u003cp\u003eSpammer math is basically any variation of the following line of reasoning: if I get one sale from a send to one thousand messages that means that I will get one hundred sales sending to one hundred thousand messages and so on until infinity. It can be expressed as \u003ccode\u003e(s=cm)\u003c/code\u003e where \u003ccode\u003es\u003c/code\u003e  is sales, \u003ccode\u003ec\u003c/code\u003e is the conversation rate, and \u003ccode\u003em\u003c/code\u003e is the number of messages sent.\u003c/p\u003e\n\u003cp\u003eThis model is based on the idea that sales will scale at a constant multiplier relative to messages sent. The foil here is \u003cem\u003eprobability\u003c/em\u003e. The assumption is that each message sent has the exact same \u003cem\u003eindependent probability\u003c/em\u003e of converting. This is false because as the number of messages increases so too does the probability of bounces and complaints, which increases the probability of sender reputation problems which in turn causes the probability of conversions to increasingly diminish. In economics this is often referred to as the \u003cem\u003elaw of diminishing returns\u003c/em\u003e.\u003c/p\u003e","title":"Spammer Math"},{"content":"Sending mail to people who didn’t ask for it is often just asking for trouble. Having people give you permission to send to them is much better.\nIn an ideal world you want first-party consent meaning that people directly subscribed to your list. You have measures in place to confirm that they really did sign up and someone didn’t just stuff their address into a subscription form. These people want your emails.\nIn a slightly less ideal world you have second-party consent. This means that another organization shared their list of first party consented subscribers with you by prior arrangement. Provided that the arrangement was clearly communicated to the subscribers at the point of acquisition then this is mostly fine. These people probably have an interest in your emails and are likely expecting to hear from you.\nIn a not so ideal world you are working with third-party consent. This means that first party consent was obtained at some point somewhere sometime for something broadly related to why you now want to reach them. This is the consent level you hope for if you use a data broker and not just scraped or stolen data. These contacts don’t know you. There is no relationship. It’s a stretch to say they really consented. They clicked a box at some point in their lives and now they ended up on your list. Treat these strangers with the utmost care and respect. Your first mail to them should be an introduction not a pitch; tell them how they ended up on your list and how to get off it. Success here means earning trust, not jumping in with a special offer.\nWhile permission is often a sliding scale of likely success with first-party consent being the most optimal, it doesn\u0026rsquo;t have to be. At scale there are strategies where programs that use third-party consent can be successful without a blast radius of bounces and complaints.\nOf course there is also the chance that you are operating with zero consent to contact people. Outside of spamming there are some legitimate scenarios for doing this but that\u0026rsquo;s a separate post.\n","permalink":"https://emaildeliverabilityexplained.com/posts/2026/08/why-permission-is-important/","summary":"\u003cp\u003eSending mail to people who didn’t ask for it is often just asking for trouble. Having people give you permission to send to them is much better.\u003c/p\u003e\n\u003cp\u003eIn an ideal world you want \u003cstrong\u003efirst-party\u003c/strong\u003e consent meaning that people directly subscribed to your list. You have measures in place to confirm that they really did sign up and someone didn’t just stuff their address into a subscription form. These people want your emails.\u003c/p\u003e","title":"Why permission is important"},{"content":"Google recently proposed a new method for verifying that an email address exists without sending a verification message to the address. They are calling it the Email Verification Protocol and there is an associated Internet Draft.\nThe idea is that the verification process all happens within the web browser at the point of address submission instead of being split between the website and wherever email lives. Not using email to verify the validity of an address removes friction such as sending delays and message filtering false-positives.\nGoogle are currently running a trial with Chrome and Gmail but other providers may also apply.\nIf the protocol can be further developed to work at internet scale and not be limited to a handful of large hosted email providers then this will be a useful addition to the ecosystem.\n","permalink":"https://emaildeliverabilityexplained.com/posts/2026/07/google-email-verification-protocol/","summary":"\u003cp\u003eGoogle recently proposed a new method for verifying that an email address exists without sending a verification message to the address. They are calling it the \u003cem\u003eEmail Verification Protocol\u003c/em\u003e and there is an associated \u003ca href=\"https://datatracker.ietf.org/doc/draft-hardt-email-verification/\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003eInternet Draft\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eThe idea is that the verification process all happens within the web browser at the point of address submission instead of being split between the website and wherever email lives. Not using email to verify the validity of an address removes friction such as sending delays and message filtering false-positives.\u003c/p\u003e","title":"Proposed Email Verification Protocol"},{"content":"Many senders have concerns about sending bulk email with PDF attachments. ESPs often advise customers against doing so and suggest alternate solutions like linking to a web portal that has the PDF file. This is all very sensible.\nBut what happens if you must send an PDF attachment due to a regulatory or some other mandatory requirement - is the campaign guaranteed to fail?\nThe answer is no. It is possible to send a PDF attachment as part of a bulk campaign and give it a very good chance of reaching inboxes.\nTo understand how, you need to understand what a PDF really is.\nWhat is a PDF? The Portable Document Format dates back to 1993 when it was created by Adobe (then known as Adobe Systems). It became an ISO standard in 2008.\nPDF files contain everything needed to represent a document such as fonts and images. But they can also include multi-media and executable content along with interactive elements such as forms that can be connected to an internet-hosted resource.\nHistorically the format\u0026rsquo;s versatility, vulnerabilities in the most common PDF reader, and how common email clients handled PDFs caused them to be treated with suspicion by message filters. At one point viruses were being embedded in PDF attachment as a way to avoid traditional defences.\nWhile the security and email landscape has changed, the interactive and executable capabilities of PDFs can still paint a target on them when they are part of a bulk campaign.\nPDF/A PDF has a number of spin-off sub-formats intended for specific purposes. One of these formats is PDF/A which is intended for archiving information. Conveniently this format also does not support the majority of elements which message scanners tend to find objectionable.\nUsing the PDF/A format for attachments in your breach notifications or mandated communications will give them the best chance of not being unfairly targeted. This tactic works not because filters give PDF/A an automatic pass, but because it will prevent you from accidentally including some potentially objectionable embedded content when creating the PDF.\nOf course there are many other best practices around mandated communications, but that will be a separate post.\n","permalink":"https://emaildeliverabilityexplained.com/posts/2026/07/pdf-bulk-mail-deliverability/","summary":"\u003cp\u003eMany senders have concerns about sending bulk email with PDF attachments.  ESPs often advise customers against doing so and suggest alternate solutions like linking to a web portal that has the PDF file. This is all very sensible.\u003c/p\u003e\n\u003cp\u003eBut what happens if you \u003cem\u003e\u003cstrong\u003emust\u003c/strong\u003e\u003c/em\u003e send an PDF attachment due to a regulatory or some other mandatory requirement - is the campaign guaranteed to fail?\u003c/p\u003e\n\u003cp\u003eThe answer is \u003cstrong\u003eno\u003c/strong\u003e. It is possible to send a PDF attachment as part of a bulk campaign and give it a very good chance of reaching inboxes.\u003c/p\u003e","title":"PDFs, bulk mail, and deliverability"},{"content":"I mentioned in a previous post that DKIM and SPF have known vulnerabilities. SPF has two that are currently being exploited.\nThe first one exploits over-broad include mechanisms and what constitutes SPF being considered to pass. For example if the SPF record for domain.victim looked like this:\nv=spf1 +include:_spf.google.com +include:hosting.provider ~all If you can control an IP within the range covered by hosting.provider then you can do something like this:\nSMTP HELO/EHLO hostname: domain.hacker\nEnvelope address: nobody@nonexistant.domain.victim\n5322.From address: \u0026ldquo;Your Invoice\u0026rdquo; nobody@nonexistant.domain.victim\nWhile there is a non-existent envelope domain there is a valid HELO/EHLO one. The sending IP is listed in the SPF record of domain.hacker. The vulnerability being exploited here is that SPF protocol will \u0026ldquo;fall-back\u0026rdquo; to checking the domain in the HELO/EHLO if there is a problem checking the envelope domain. That means that there is a non-zero chance of this message registering as a PASS for SPF depending on how SPF is evaluated by the receiver. This vulnerability was researched at scale for the BreakSPF paper1.\nThere is a second related vulnerability that is more to do with poorly configured infrastructure and loose authentication checks than a weakness in the protocol itself. It is commonly referred to as an SPF Upgrade Attack and is being activity exploited.\nThe risk of over-broad SPF include mechanisms was understood by the authors of the original RFC but back then most organizations hosted their email on-site and the include mechanism was intended to capture edge cases, not be the norm. The latest revision to the DMARC specification includes a policy for handling non-existent domains along with a clarification that DMARC only considers SPF to pass if it is on the envelope domain.\nWang, C., Kuranaga, Y., Wang, Y., Zhang, M., Zheng, L., Li, X., Chen, J., Duan, H., Lin, Y., \u0026amp; Pan, Q. (2024). BreakSPF: How Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet. Proceedings 2024 Network and Distributed System Security Symposium. https://doi.org/10.14722/ndss.2024.23113\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://emaildeliverabilityexplained.com/posts/2026/07/vulnerabilities-in-spf/","summary":"\u003cp\u003eI mentioned in a \u003ca href=\"/posts/2026/06/dkim2-is-on-the-way/\"\n  \n  \n\u003eprevious post\u003c/a\u003e that DKIM and SPF have known vulnerabilities. SPF has two that are currently being exploited.\u003c/p\u003e\n\u003cp\u003eThe first one exploits over-broad \u003cem\u003einclude\u003c/em\u003e mechanisms and what constitutes SPF being considered to pass. For example if the SPF record for \u003cstrong\u003edomain.victim\u003c/strong\u003e looked like this:\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ev=spf1 +include:_spf.google.com +include:hosting.provider ~all\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eIf you can control an IP within the range covered by \u003cem\u003ehosting.provider\u003c/em\u003e then you can do something like this:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSMTP HELO/EHLO hostname:\u003c/strong\u003e \u003cem\u003edomain.hacker\u003c/em\u003e\u003c/p\u003e","title":"Vulnerabilities in SPF"},{"content":"I mentioned in a previous post that DKIM and SPF have known vulnerabilities. The main weakness with DKIM is that you can replay the messages.\nBy design DKIM signed messages are replay-able meaning that under certain conditions you can send a DKIM signed message from A to B then B can replay the unmodified messages to C (or any number of recipients) and the signature will still validate. This works because DKIM does not sign the return-path message header or concern itself with message delivery at all. After all DKIM was always about content signing.\nThe potential to exploit replaying DKIM messages was understood and documented since the earliest days of the protocol but was not seen as a major risk. However when some mailbox providers began to associate sender reputation with DKIM signing domains replaying stopped being a feature and became a vulnerability.\nBack to our A,B, and C example. Imagine that A has a DKIM signing domain that is considered to have a good reputation. If the attacker B can induce A to send them an email containing content that they control then B can replay that message to C and it will still DKIM validate and carry A\u0026rsquo;s sending reputation. This is referred to as a DKIM Reply Attack.\nReplay attacks are observed in the wild exploiting may different services to leverage the reputation of their DKIM domains. Typically vulnerable services have the following characteristics:\nThey are have widespread use (for example video-conferencing or document signing services) They offer a free tier or have a trial subscription There is minimal validation of new users New users can induce the service to send an email with content they control to an address they control Point 4 above is the main problem because it often describes the normal operation of a service and is the reason why the attack is not easy to defend against.\nReplay-ability also means that the original originator and intended recipient of a message can not be accurately determined.\n","permalink":"https://emaildeliverabilityexplained.com/posts/2026/07/dkim-replay/","summary":"\u003cp\u003eI mentioned in a \u003ca href=\"/posts/2026/06/dkim2-is-on-the-way/\"\n  \n  \n\u003eprevious post\u003c/a\u003e that DKIM and SPF have known vulnerabilities. The main weakness with DKIM is that you can replay the messages.\u003c/p\u003e\n\u003cp\u003eBy design DKIM signed messages are \u003cem\u003ereplay-able\u003c/em\u003e meaning that under certain conditions you can send a DKIM signed message from \u003cstrong\u003eA\u003c/strong\u003e to \u003cstrong\u003eB\u003c/strong\u003e then \u003cstrong\u003eB\u003c/strong\u003e can replay the unmodified messages to \u003cstrong\u003eC\u003c/strong\u003e (or any number of recipients) and the signature will still validate. This works because DKIM does not sign the \u003cem\u003ereturn-path\u003c/em\u003e message header or concern itself with message delivery at all. After all DKIM was always about \u003cem\u003econtent signing\u003c/em\u003e.\u003c/p\u003e","title":"DKIM Replay"},{"content":"RFC 8619 was published in July 2019 with the status of Experimental and describes the Authenticated Received Chain (ARC) protocol. On 16 April 2026 the DMARC Working Group (who originated ARC) voted to re-charter the group for the sole purpose of changing the status of the RFC to Historic and declaring the ARC experiment concluded. I was one of those who voted in favor.\nThe WG has six months to agree on actually doing this. If successful then there will be no further updates to the specification and deployment will not be recommended.\nThe reason for wanting to conclude the experiment is very simple: adoption was extremely low and those who did adopt it at scale did not find it useful.\nBackground ARC tried to solve the \u0026ldquo;indirect email flows\u0026rdquo; problem. This is also informally referred to as the \u0026ldquo;mailing list\u0026rdquo; problem as they are the main originators of these flows.\nMailing lists are email based discussion groups. The flow works like this: an author replies to a message on a list that they are subscribed to, the reply goes to the Mailing List Manager (MLM) software which then resends the message to the other people on that list, preserving the author\u0026rsquo;s From address.\nYou can see the problem. For context, mailing lists worked fine for 30 plus years and pre-date all email authentication protocols. They also form the backbone of how the IETF gets work done.\nIf the MLM modifies a message, for example, by adding a footer or prefixing the subject line with the list name, then DKIM is invalidated which will cause deliverability problems. If the author\u0026rsquo;s domain has an enforcing DMARC policy then the message is guaranteed to get into widespread difficulties.\nMany MLMs use workarounds such as setting the From address of all messages to the list address. This degrades the mailing list experience for many as it can break searches.\nAnother example of an indirect flow is alumni mail forwarding arrangements where mail sent to the old address of the student is forwarded on to their current address all while preserving the From address. This type of flow also pre-dates all authentication protocols.\nWhat ARC does ARC attempts to create a \u0026ldquo;chain of trust\u0026rdquo; by cryptographically signing the authentication evaluation (SPF, DKIM, and DMARC status) each time a message passed through an ARC-aware email system. So in a three-hop flow of A -\u0026gt; B -\u0026gt; C, C could use ARC to tell if the message from A to B passed authentication before B sent it on with a preserved \u0026ldquo;spoofed\u0026rdquo; From address.\nIn theory this allowed originators of indirect mail flows to use ARC to continue to operate as they always did but in a post-authentication world. The reality was a little different.\nWeaknesses with ARC ARC has no protections against forgery since it does not require that ARC signatures from previous hops verify. That means that anyone can build an ARC chain that contains incorrect information. This severely limited ARC\u0026rsquo;s usefulness since it needs the receiver to trust the sender - and if you trust the sender then why do you even need ARC? Closely connected to this is that ARC allows messages that would normally fail DMARC tests to land in inboxes but provides no assurances that the messages are not forged.\nWhat\u0026rsquo;s next? The main focus on email authentication in 2026 is DKIM2 which incorporates learning from ARC.\n","permalink":"https://emaildeliverabilityexplained.com/posts/2026/06/plans-to-put-arc-out-to-pasture/","summary":"\u003cp\u003e\u003ca href=\"https://datatracker.ietf.org/doc/html/rfc8617\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003eRFC 8619\u003c/a\u003e was published in July 2019 with the status of \u003cem\u003eExperimental\u003c/em\u003e and describes the Authenticated Received Chain (ARC) protocol. On 16 April 2026 the DMARC Working Group (who originated ARC) voted to \u003ca href=\"https://datatracker.ietf.org/doc/charter-ietf-dmarc/04/\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003ere-charter\u003c/a\u003e the group for the sole purpose of changing the status of the RFC to \u003cem\u003eHistoric\u003c/em\u003e and declaring the ARC experiment concluded. I was one of those who voted in favor.\u003c/p\u003e\n\u003cp\u003eThe WG has six months to agree on actually doing this. If successful then there will be no further updates to the specification and deployment will not be recommended.\u003c/p\u003e","title":"Plans to put ARC out to pasture"},{"content":"If you would like to discuss matters such as bulk orders, licensing, syndication, or to report an error, please use the below email address.\nEmail: \u0026#32;\u0026#32; You may also contact Ken directly by sending a message to \u0026#32;\u0026#32; ","permalink":"https://emaildeliverabilityexplained.com/contact/","summary":"\u003cp\u003eIf you would like to discuss matters such as bulk\norders, licensing, syndication, or to report an error, please use the below\nemail address.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eEmail:\u003c/strong\u003e \n\u003cstyle\u003e\n  #span-ceec4c58.cloaked-e-mail:before {\n    content:attr(data-domain) \"\\0040\" attr(data-user);\n    unicode-bidi:bidi-override;\n    direction:rtl;\n  }\n\u003c/style\u003e\n\u0026#32;\u003cspan class=\"cloaked-e-mail\" data-user=\"eciffo\" data-domain=\"moc.llocsirdonek\" id=\"span-ceec4c58\"\u003e\u003c/span\u003e\u0026#32;\n\n\u003cscript id=\"script-ceec4c58\"\u003e\n  var scriptTag = document.getElementById(\"script-ceec4c58\");\n  var link = document.createElement(\"a\");\n  var address = \"eciffo\".split('').reverse().join('') + \"@\" + \"moc.llocsirdonek\".split('').reverse().join('');\n  link.href = \"mailto\" + \":\" + address;\n  link.innerText = address.split('?')[0];\n  scriptTag.parentElement.insertBefore(link, scriptTag.previousElementSibling);\n  scriptTag.parentElement.removeChild(scriptTag.previousElementSibling)\n\u003c/script\u003e\n\n\u003c/p\u003e\n\u003cp\u003eYou may also contact Ken directly by sending a message to \n\u003cstyle\u003e\n  #span-178d0622.cloaked-e-mail:before {\n    content:attr(data-domain) \"\\0040\" attr(data-user);\n    unicode-bidi:bidi-override;\n    direction:rtl;\n  }\n\u003c/style\u003e\n\u0026#32;\u003cspan class=\"cloaked-e-mail\" data-user=\"nek\" data-domain=\"moc.llocsirdonek\" id=\"span-178d0622\"\u003e\u003c/span\u003e\u0026#32;\n\n\u003cscript id=\"script-178d0622\"\u003e\n  var scriptTag = document.getElementById(\"script-178d0622\");\n  var link = document.createElement(\"a\");\n  var address = \"nek\".split('').reverse().join('') + \"@\" + \"moc.llocsirdonek\".split('').reverse().join('');\n  link.href = \"mailto\" + \":\" + address;\n  link.innerText = address.split('?')[0];\n  scriptTag.parentElement.insertBefore(link, scriptTag.previousElementSibling);\n  scriptTag.parentElement.removeChild(scriptTag.previousElementSibling)\n\u003c/script\u003e\n\n\u003c/p\u003e","title":"Contact Details"},{"content":"The DKIM Working Group are developing a spiritual successor to DKIM. They have named it DKIM2 but it is more of its own thing than an iterative new version of the original DKIM protocol.\nAs of now (June 2026) it is still going through the drafting process so there is no RFC or stable specification to develop against. Ideas are still being stress tested and edge cases considered. The latest Internet-Draft can be viewed here and there is also an explanatory website operated by the WG here.\nFrom the direction it is taking we can see some core concepts:\nIt will be (initially at least) backward compatible with DKIM, using the same DKIM-Signature message header and public keys It will use a \u0026ldquo;chain of trust\u0026rdquo; like ARC but crucially you can undo previous assertions and cryptographically verify them Normally my attitude with anything at IETF draft stage is not to hold my breath. It\u0026rsquo;s a slow process to design something that will meets IETF requirements around universality, interoperability, security, and privacy. And there is a large graveyard of ideas that never progressed from a draft or qualified as RFCs.\nHowever DKIM2 is been driven with focus and momentum by some large senders and receivers. It would not surprise me if this got assigned an RFC by the end of 2026 or early 2027. I could be wrong though.\n","permalink":"https://emaildeliverabilityexplained.com/posts/2026/06/dkim2-is-on-the-way/","summary":"\u003cp\u003eThe \u003ca href=\"https://datatracker.ietf.org/wg/dkim/about/\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003eDKIM Working Group\u003c/a\u003e are developing a spiritual successor to DKIM. They have named it DKIM2 but it is more of its own thing than an iterative new version of the original DKIM protocol.\u003c/p\u003e\n\u003cp\u003eAs of now (June 2026) it is still going through the drafting process so there is no RFC or stable specification to develop against. Ideas are still being stress tested and edge cases considered. The latest Internet-Draft can be viewed \u003ca href=\"https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003ehere\u003c/a\u003e and there is also an explanatory website operated by the WG \u003ca href=\"https://dkim2.com\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003ehere\u003c/a\u003e.\u003c/p\u003e","title":"DKIM2 is (probably) on the way, and sooner than you think"},{"content":"The original DMARC specification was published back in March 2015 as RFC 7489 and had a status of \u0026ldquo;Informational\u0026rdquo;. A new revision published in May 2026 breaks the specification into multiple RFCs and has a status of “Proposed standard”. This is the first step to becoming an Internet Standard.\nThe new DMARC RFCs:\nRFC 9989 - core protocol specification RFC 9990 - aggregate reporting specification RFC 9991 - failure reporting specification In the approximately ten years between these two revisions the specification has been refined but not radically altered. The updated specification is fully backward compatible with the previous one.\nNone of the changes matter unless you are implementing DMARC. The new specification will have no impact on deliverability or email program performance.\n","permalink":"https://emaildeliverabilityexplained.com/posts/2026/06/dmarc-is-closer-to-becoming-a-standard/","summary":"\u003cp\u003eThe original DMARC specification was published back in March 2015 as \u003cem\u003eRFC 7489\u003c/em\u003e and had a status of \u0026ldquo;Informational\u0026rdquo;.  A new revision published in May 2026 breaks the specification into multiple RFCs and has a status of “Proposed standard”.  This is the first step to becoming an Internet Standard.\u003c/p\u003e\n\u003cp\u003eThe new DMARC RFCs:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://datatracker.ietf.org/doc/html/rfc9989\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003eRFC 9989\u003c/a\u003e - core protocol specification\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://datatracker.ietf.org/doc/html/rfc9990\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003eRFC 9990\u003c/a\u003e - aggregate reporting specification\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://datatracker.ietf.org/doc/html/rfc9991\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003eRFC 9991\u003c/a\u003e - failure reporting specification\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIn the approximately ten years between these two revisions the specification has been refined but not radically altered. The updated specification is fully backward compatible with the previous one.\u003c/p\u003e","title":"DMARC is closer to becoming a standard"},{"content":"Just a short note to say that yes the website is still alive! Apologies for the radio silence. The site\u0026rsquo;s hosting has been migrated to something more manageable and faster.\nThe blog will start to get more regular updates on changes affecting the email industry. There\u0026rsquo;s a backlog of unpublished posts in various degrees of completeness and also some very interesting changes happening in 2026.\nStay tuned.\n","permalink":"https://emaildeliverabilityexplained.com/posts/2026/06/website-move-and-site-update/","summary":"\u003cp\u003eJust a short note to say that \u003cstrong\u003eyes\u003c/strong\u003e the website is still alive! Apologies for the radio silence. The site\u0026rsquo;s hosting has been migrated to something more manageable and faster.\u003c/p\u003e\n\u003cp\u003eThe blog will start to get more regular updates on changes affecting the email industry. There\u0026rsquo;s a backlog of unpublished posts in various degrees of completeness and also some very interesting changes happening in 2026.\u003c/p\u003e\n\u003cp\u003eStay tuned.\u003c/p\u003e","title":"Website Move and Site Update"},{"content":"Chapter 1 – Introduction Frames email deliverability around four principles that guide all the best practices.\nChapter 2 – How Internet Email Works Explains the basic concepts and technologies behind how internet email works.\nChapter 3 – Message Filters and Message (Sample chapter - download PDF) Covers message filters and streams. It explains the different types and purposes of filters. It also explains what messages streams are and how they can be used to work with filters.\nChapter 4 – Measuring Email Deliverability Explains how to measure deliverability to understand if you have a deliverability problem.\nChapter 5 – Blacklists and Spam Traps Covers the different types of spam blocklists, how you get on and off them, and which ones you should be worried about. Spam traps, and their relationship to blocklists, are also covered.\nChapter 6 – Email Address Validation Explains how email address validation works, and when to use these services.\nChapter 7 – Bounces and List Hygiene Covers bounce messages and the importance of keeping your contact list in good order.\nChapter 8 – Domain and IP reputation Explains how reputation filtering works and how to stay on top of it.\nChapter 9 – Content Filters Explains how filters that operate on the body of an email work.\nChapter 10 – Engagement Filters Covers how recipient engagement influences deliverability.\nChapter 11 – Email Authentication Explains the main email authentication protocols and how they can significantly influences deliverability.\nChapter 12 – Conclusion – Putting it all together This very short chapter wraps it all up.\n","permalink":"https://emaildeliverabilityexplained.com/contents/","summary":"\u003ch4 id=\"chapter-1--introduction\"\u003eChapter 1 – Introduction\u003c/h4\u003e\n\u003cp\u003eFrames email deliverability around four principles that guide all the best practices.\u003c/p\u003e\n\u003ch4 id=\"chapter-2--how-internet-email-works\"\u003eChapter 2 – How Internet Email Works\u003c/h4\u003e\n\u003cp\u003eExplains the basic concepts and technologies behind how internet email works.\u003c/p\u003e\n\u003ch4 id=\"chapter-3--message-filters-and-message-sample-chapter---download-pdf\"\u003eChapter 3 – Message Filters and Message \u003ca href=\"/pdf/Email-Deliverability-Explained-2nd-Ed-SAMPLE-CHAPTER.pdf\"\n  \n  \n\u003e(Sample chapter - download PDF)\u003c/a\u003e\u003c/h4\u003e\n\u003cp\u003eCovers message filters and streams. It explains the different types and purposes of filters. It also explains what messages streams are and how they can be used to work with filters.\u003c/p\u003e","title":"Contents"},{"content":"Ken O\u0026rsquo;Driscoll has been working in the technology sector, and mostly around email, for approximately 25 years.\nIn 2023, he published the second edition of Email Deliverability Explained. The first edition was published in 2017.\nKen is currently the Head of Deliverability for Upland Software.\nLinkedIn: https://linkedin.com/in/kenod\nPersonal website: https://kenodriscoll.com/\n","permalink":"https://emaildeliverabilityexplained.com/the-author/","summary":"\u003cimg alt=\"The Book\" loading=\"lazy\" src=\"/img/author_image.png\" style=\"float:left; margin-right:20px;\"\u003e\u003cp\u003eKen O\u0026rsquo;Driscoll has been working in the technology sector, and mostly around email, for approximately 25 years.\u003c/p\u003e\n\u003cp\u003eIn 2023, he published the second edition of Email Deliverability Explained. The first edition was published in 2017.\u003c/p\u003e\n\u003cp\u003eKen is currently the Head of Deliverability for Upland Software.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinkedIn:\u003c/strong\u003e \u003ca href=\"https://linkedin.com/in/kenod\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003ehttps://linkedin.com/in/kenod\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ePersonal website\u003c/strong\u003e: \u003ca href=\"https://kenodriscoll.com/\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003ehttps://kenodriscoll.com/\u003c/a\u003e\u003c/p\u003e","title":"The Author"},{"content":"Request For Comments (RFCs) are documents published by the Internet Engineering Task Force (IETF) which describe internet operations and protocols. Some are published standards, others are on their way to be standards. Other RFC are published on an experimental or informational basis. There is even some humour.\nListed on this page are some prominent RFCs associated with topics covered in the book. If you need a deep understanding of an internet protocol or intend to write software that includes a protocol, the RFCs are the place to start. The principal that drives the IETF is interoperability, meaning that software that follows RFCs has a very good chance of working with other software written by different vendors.\nCore Internet Email RFC 1035 Domain Names - Implementation and Specification\nThis is the core internet standard on DNS. There are many more associated RFCs but this is where to start. A solid understanding of DNS is essential for understanding email and by extension, deliverability.\nRFC 5321 Simple Mail Transfer Protocol\nThis is where the SMTP protocol is defined, including the 5321.MAILFROM field (also known as the return-path, envelope header, or the bounce address). An understanding of the SMTP protocol is essential for diagnosing many deliverability problems.\nRFC 5322 Internet Message Format\nThis is where the core structure of email messages is defined, including the 5322. From field. This is the visible From address you see in messages. A solid understanding of this RFC is also essential.\nRFC 5598 Internet Mail Architecture\nThis RFC is informational and acts as a lexicon for describing how internet mail works. This is touched on this in the book, when the technical terms for email servers and clients are covered. However, there are many more technical terms and distinctions which are very useful to understand if you plan on having a technical conversation about email.\nMulti-purpose Internet Mail Extensions (MIME) RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies\nRFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types\nRFC 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text\nRFC 4021 Registration of Mail and MIME Header Fields\nRFC 4288 Media Type Specifications and Registration Procedures\nRFC 4289 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures\nRFC 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples\nRFC 2387 The MIME Multipart/Related Content-type\nWhile you may take sending a single message with file attachments, inline images, html, and plain text for granted - there was a lot of work done to get internet email to that point. If you intend to write any piece of code which generates or parses MIME encoded messages, I would strongly advise that you familiarise yourself with these RFCs first. A good understanding of MIME, and specifically how boundaries work, is essential for diagnosing certain types of deliverability problems.\nEmail Authentication RFC 6376 DomainKeys Identified Mail (DKIM) Signatures\nThis is the base DKIM specification. DKIM has a lot more associated RFCs of proposed additions and improvements. That\u0026rsquo;s mainly because for a long time, DKIM was seen as the solution to many problems. That changed a bit when DMARC appeared.\nRFC 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1\nThis is where SPF is defined. There is a lot more to the SPF protocol than was covered in the book. Deliverability people need a thorough understanding SPF to do their work properly.\nRFC 9989 Domain-based Message Authentication, Reporting, and Conformance (DMARC)\nRFC 9990 covers how DMARC aggregate reports work and RFC 9991 covers failure reports.\nA good understanding of DMARC is needed to correctly understand the symptoms of a mis-configured DMARC deployment.\nNOTE: RFC 7489 was the original DMARC RFC and you will see many references to it. This was depreciated mid-2026 and replaced with the above three RFCs as part of the process of moving it towards becoming an internet standard.\nRFC 7960 Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows\nThis RFC describes the deliverability problems that DMARC can cause when the recipient has their mail programmatically forwarded to another destination. The short answer is SPF alignment gets broken because the forwarder\u0026rsquo;s IP address is not listed in the (aligned) SPF record. Any process that alters the message subject, body, or certain headers will cause DKIM to break. If you are doing anything with DMARC, understanding the \u0026ldquo;forwarding problem\u0026rdquo; is crucial.\nRFC 8601 Message Header Field for Indicating Message Authentication Status\nThis is the RFC behind the Authentication-Results header. It is probably of academic interest to anyone but those who need to write software that references it.\nRFC 8617 The Authenticated Received Chain (ARC) Protocol\nARC is an experimental protocol which is intended to help DMARC overcome indirect mail-flows (i.e., forwarding) between trusted parties. It\u0026rsquo;s too advanced to cover in the book but you should know about it if you need to do anything with DMARC.\nTransport Encryption RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security\nRFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)\nRFC 8460 SMTP TLS Reporting\nRFC 8561 SMTP MTA Strict Transport Security (MTA-STS)\nTransport (the connection between two machines) encryption is briefly touched upon the book. These RFCs go into a lot more detail about developments in that area. Many modern transport encryption schemes are designed for the modern world, not the world of trust the early internet evolved from. Consequently most of these schemes break interoperability by implementing enforcing, as opposed to opportunistic encryption. Deliverability problems caused by transport encryption are mainly the result of either it not being set up properly at one end, or one end trying to force a particular type of encryption or encryption protocol.\n1-click unsubscribe RFC 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields\nRFC 8058 Signaling One-Click Functionality for List Email Headers\nThere are thousands of RFCs. This page will be periodically updated with prominent RFC that may be useful to people in the deliverability field. Ken reads all of the RFCs so you do not have to!\n","permalink":"https://emaildeliverabilityexplained.com/useful_rfcs/","summary":"\u003cp\u003eRequest For Comments (RFCs) are documents published by the \u003ca href=\"https://ietf.org/\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003eInternet Engineering Task Force\u003c/a\u003e (IETF) which describe internet operations and protocols. Some are published standards, others are on their way to be standards. Other RFC are published on an experimental or informational basis. There is even some \u003ca href=\"https://datatracker.ietf.org/doc/html/rfc968\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003ehumour\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eListed on this page are some prominent RFCs associated with topics covered in the book. If you need a deep understanding of an internet protocol or intend to write software that includes a protocol, the RFCs are the place to start. The principal that drives the IETF is interoperability, meaning that software that follows RFCs has a very good chance of working with other software written by different vendors.\u003c/p\u003e","title":"Useful Request for Comments (RFCs)"},{"content":"This page contains a non-exclusive list of potential vendors and providers to aid readers researching more about a particular topic. No endorsement is intended. No sponsorship was received. Omission of a particular vendor does not mean anything. This page is intended as a starting point, not a definitive directory.\nEmail Validation (Chapter 6) Email Hippo https://emailhippo.com/\nKickbox https://kickbox.com/\nThere are many other email validation providers. As discussed in the book, readers are strongly advised to carry out proper due-diligence before selecting a vendor in this space.\nIP Certification (Chapter 8) Certified Senders Alliance https://certified-senders.org/\nSuretyMail https://www.isipp.com/\nValidity https://www.validity.com/\nUseful Block Lists and filters contact points (Chapters 5 and 8) The Spamhaus Project https://spamhaus.org/\nInvaluement https://www.invaluement.com/\nNoSolicitado https://www.nosolicitado.org/ (South America mostly)\nProofpoint https://ipcheck.proofpoint.com/\nBarracuda https://www.barracudacentral.org/rbl\nCloudmark Sender Intelligence https://csi.cloudmark.com/en/reset\nBroadcom (formerally Symantec) https://ipremoval.sms.symantec.com/\nMcAfee SmartFilter and WebWasher https://sitelookup.mcafee.com/\nWebroot BrightCloud https://brightcloud.com/tools/url-ip-lookup.php\nSURBL https://surbl.org/\nDomain and IP Reputation (Chapter 8) Talos Intelligence Project https://talosintelligence.com/\nIBM X-Force Exchange https://exchange.xforce.ibmcloud.com/\nDMARC report dashboards and implementation consultants (Chapter 11) EasyDMARC https://easydmarc.com\nOnDMARC (by Red Sift) https://redsift.com/pulse-platform/ondmarc\nValimail https://www.valimail.com/\nReputation Monitoring (Chapters 5 and 8) Postmastery https://www.postmastery.com/ Validity https://www.validity.com/ Inbox Monster https://inboxmonster.com/ MxToolbox https://mxtoolbox.com/ Automated monitoring is very useful, but having a core understanding of your email program is essential. Do not purely rely on automated monitoring.\nDeliverability consultants Word to the Wise https://wordtothewise.com/ Postmastery https://www.postmastery.com/ Email checkers (for \u0026ldquo;spammyness\u0026rdquo;) If you want to know why this list category will always be blank, read the book!\n","permalink":"https://emaildeliverabilityexplained.com/vendors/","summary":"\u003cp\u003eThis page contains a non-exclusive list of potential vendors and providers to aid readers researching more about a particular topic. No endorsement is intended. No sponsorship was received. Omission of a particular vendor does not mean anything. This page is intended as a starting point, not a definitive directory.\u003c/p\u003e\n\u003ch4 id=\"email-validation-chapter-6\"\u003eEmail Validation (Chapter 6)\u003c/h4\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003eEmail Hippo \u003ca href=\"https://emailhippo.com/\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003ehttps://emailhippo.com/\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eKickbox \u003ca href=\"https://kickbox.com/\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003ehttps://kickbox.com/\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThere are many other email validation providers. As discussed in the book, readers are strongly advised to carry out proper due-diligence before selecting a vendor in this space.\u003c/p\u003e","title":"Vendors and Providers"},{"content":"2024 Update: Gmail and Yahoo! Change Their Sending Requirements Last updated: 10 August 2024\nRefer to Chapter 8 (Sender Reputation) and Chapter 11 (Email Authentication) of Email Deliverability Explained (2nd edition) for background information on topics discussed in this post.\nBack in October 2023 Google and Yahoo! simultaneously announced that they would begin enforcing new requirements for bulk senders from February 2024 onwards.\nBy June 2024 all of the new requirements are officially being enforced.\nThese requirements currently only apply to their personal use domains, such as gmail.com, yahoo.com, and aol.com. Yahoo! Japan (yahoo.co.jp) is explicitly not included. Bulk senders are broadly defined as those sending thousands of messages on a daily basis to these domains.\nSome of the requirements are already best practices which many senders are likely to already have in place. Other requirements are may require additional effort to implement.\nIf you are sending bulk emails to Google or Yahoo! domains you need to understand this. The main requirements from both providers can be summarised as follows:\nUse Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM)\nSPF (RFC 7208) controls who can send messages from your domain. DKIM (RFC 6376) enables a domain to be cryptographically associated with an email message.\nSPF has been a de facto requirement for quite some time and implementation is typically part of the onboarding process with email and CRM providers.\nRemember, SPF works on the sending domain, which is the domain used the return-path message header of a message. So that is the domain where your SPF record needs to be published.\nDKIM has also been a requirement for bulk messages for some time. However, its implementation can be inconsistent. Ideally DKIM should be aligned, meaning that the signing domain matches the From domain in the message. However, this may not be configured by default with all email and CRM providers. Aligning DKIM helps message filters identify your mail flow, which can aid building sending reputation.\nIf you manage your own sending infrastructure then you should double check that SPF is valid (passes) and your are DKIM signing with aligned domains.\nAdd a DMARC record and ensure it passes\nThe new requirement is that a bulk sender must publish a minimum of a non-enforcing DMARC policy and that it passes. That means that either SPF or DKIM needs to be aligned. As I mentioned above, aligning DKIM is preferable.\nBoth providers also (added December 2023) hint that they favour DMARC reporting to be enabled. This is extremely unlikely to be enforced, however it is generally a good idea, provided that you read the reports.\nIf you already have DMARC deployed you are probably covered but check with your DMARC vendor to be sure. Otherwise, follow the configuration recommendations from your email and CRM providers.\nKeep your spam rate below a certain threshold\nSpam rate is the percentage of messages recipients mark as spam over a sample period, usually 24 hours.\nBoth providers say that senders who consistently exceed a spam rate of 0.3% will have a much higher chance of seeing spam placement. Google (added December 2023) specifically say to aim to, on average, not exceed 0.1% and never consistently exceed 0.3%.\nTo put this into perspective, if you send 5,000 messages and 15 recipients mark your message as spam, that is your 0.3% threshold right there. Or, if you send 1 million messages, 3,000 complaints is the 0.3% threshold.\nIt is important to note that these thresholds are per-provider, meaning a spam rate of 0.1% with Google and 0.1% across Yahoo! is not a spam rate of 0.2%. While the new requirements are similar and there is coordination between both providers, they operate independently.\nYahoo! report the spam rate to providers via feedback loop (FBL), Google do not. To understand your spam rate with Google, you will need to sign up to their free Google Postmaster Tools portal.\nAlso, be aware that not every provider breaks out Yahoo! spam rate from the overall spam rate metric calculation. These new requirements may prompt providers to change this, but it will take time.\nThere is a lot of information in the book about how to keep your complaint rates low, but it all circles back to sending mail that recipients want to read.\nMarketing messages need to have both an unsubscribe link and a one-click unsubscribe header\nIf a message is not 100% transactional in nature then you need to provide an unambiguous unsubscribe link in the body of the message. The unsubscribe link should unsubscribe them without them having to log in or provide any additional information, other than possibly clicking a confirmation button.\nIf you use a preference centre which does not support direct unsubscribes then you will need to include a separate unsubscribe link for the campaign next to the link to the preference centre.\nYou will also need to include a one-click unsubscribe message header, which allows recipients to unsubscribe directly from supported email clients. This header is typically added transparently by email or CRM providers.\nThere are two methods to implement one-click unsubscribe headers. The original method is specified in RFC 2369 and the newer method is specified in RFC 8058. The original method is currently much more widely supported than the newer one. However, it is likely that these new requirements have prompted some vendors to plan support for the newer specification.\nOriginally Google only referenced support for RFC 8058, however as of late December (2023) they have now included RFC 2369 as being acceptable too. It is obvious what both providers prefer and you should ensure that any software you use to send messages supports RFC 8058.\nThere is also a requirement that the unsubscribe requests are honoured within two days. Given that this is simply not possible for bulk senders in certain industries to achieve, I suspect that enforcement of this requirement will be lax, and based on the sender’s other metrics.\nIf you have written your own sending software or you use a third party unsubscribe service, this requirement is something which you will need to follow up on to ensure that you are compliant.\nHave Forward-Confirmed reverse DNS (FCrDNS) on sending IPs\nFCrDNS has been a de facto requirement for many years. So it is extremely likely that any email and CRM providers that you use will already implement it.\nIf you manage your own email infrastructure then you should double check that all sending IPs have FCrDNS.\nIf you forward bulk messages or are a mailing list, then use Authenticated Receiver Chain (ARC)\nI did not cover ARC in the book because it is an experimental protocol which was not widely implemented outside large mailbox providers.\nWhen a message is forwarded programmatically, for example, between two mailbox provider, then SPF and DKIM are vulnerable to being broken since they are fragile in different ways. This can cause inbox placement issues, especially if DMARC is enabled with an enforcing policy.\nMailing lists, also known email discussion groups, “spoof” sender addresses as part of their normal operations when they forward them to the list. They do not do this maliciously, but simply because their existence pre-dates email authentication protocols such as SPF, DKIM, and DMARC.\nAuthenticated Receiver Chain (ARC) is a protocol which allows a sender to cryptographically sign the authentication status of a received message, before forwarding in to the next destination. The next receiver in line can then use ARC to understand the authentication result of the message before it was forwarded. This allows for the original authentication status of an automatically forwarded message to be preserved, which can aid inbox placement.\nThe new requirement says that if you are some type of service or intermediary that forwards bulk messages, or expects messages you send to be forwarded, then you should implement ARC and sign those messages before you send them on their merry way. This requirement is particularly relevant to mailbox providers of all sizes and anyone operating mailing lists.\nTo be clear, forwarding in the context of ARC is programmatic not manual. We are not talking about recipients forwarding messages from their email clients.\nOh, if you are wondering how a typical receiver would know whether or not to trust an ARC signature from a particular provider, that problem has yet to be solved. However, very large receivers like Google and Yahoo! have enough proprietary data on senders to enable them to make informed trust decisions. ARC signing outbound messages, regardless of their forwarding status, will not hurt deliverability and may even help with larger providers.\nEnsure that you comply existing RFCs\nA less publicised requirement is that senders are now required to fully comply with the Simple Mail Transport Protocol (RFC 5321) and the Internet Message Format (RFC 5322) specifications.\nThis requirement is only relevant if you have written your own software which constructs or sends bulk emails. Even then, you should have noticed blocks before now if you were sending malformed messages.\nI recommend especially focusing on Section 3.6 of RFC 5322 where it talks about the minimum and maximum number of permitted header fields in a message. Overloading headers is a method that is used as part of a DKIM replay attack, and that something that large providers like Google and Yahoo! are particularly susceptible to.\nIt also wound not do any harm to ensure you are rendering MIME messages properly (see resources for the RFCs).\nWrapping up\nUnless you are the email provider, the vast majority of these requirements are your responsibility to ensure they are in place. Familiarise yourself with the requirements, ideally from the actually providers (see below). Talk to your vendors, they are very likely already on top of all of this.\nIf you already use a reputation dashboard such as Everest or Inbox Monster then you already have access to Google Postmaster Tools data, just be sure to enable it. Otherwise, sign up all of your domains to Google Postmaster Tools (GPT), which been updated to show compliance status. GPT also has an API so you could also surface the data on your own ops dashboards, if that is your thing.\nI will continue to update this post if there are significant changes to the requirements.\nResources\nGoogle Email sender guidelines\nGoogle FAQ\nGoogle Gmail product blog\nYahoo! guidelines\nYahoo! FAQ\nYahoo! Postmaster blog\nUseful email related RFCs\n","permalink":"https://emaildeliverabilityexplained.com/posts/2024/08/new-sender-requirements-2024/","summary":"\u003ch4 id=\"2024-update-gmail-and-yahoo-change-their-sending-requirements\"\u003e2024 Update: Gmail and Yahoo! Change Their Sending Requirements\u003c/h4\u003e\n\u003cp\u003e\u003cem\u003eLast updated: 10 August 2024\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eRefer to Chapter 8 (Sender Reputation) and Chapter 11 (Email Authentication) of Email Deliverability Explained (2nd edition) for background information on topics discussed in this post.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eBack in October 2023 Google and Yahoo! simultaneously announced that they would begin enforcing new requirements for bulk senders from February 2024 onwards.\u003c/p\u003e\n\u003cp\u003eBy June 2024 all of the new requirements are officially being enforced.\u003c/p\u003e","title":"New Sender Requirements 2024"},{"content":"Publication - Email Deliverability Explained (second edition) is now live on Amazon Delighted to announce that the second edition of Email Deliverability Explained is officially available as of today on Amazon.\nIt took a long while to get here, but it was worth it. I have plans to release a Kindle edition at some point, but not immediately. The print edition always more popular historically. As any self-published author will tell you, it\u0026rsquo;s a team effort. I would like to thank everyone who helped make this possible. You know who you are.\n","permalink":"https://emaildeliverabilityexplained.com/posts/2023/10/email-deliverability-explained-second-edition/","summary":"\u003ch4 id=\"publication---email-deliverability-explained-second-edition-is-now-live-on-amazon\"\u003ePublication - Email Deliverability Explained (second edition) is now live on Amazon\u003c/h4\u003e\n\u003cp\u003eDelighted to announce that the second edition of Email Deliverability Explained is officially available as of today on \u003ca href=\"https://www.amazon.com/dp/B0CJBPLLFN\"\n  \n  \n    target=\"_blank\" rel=\"noopener noreferrer\"\n  \n\u003eAmazon\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eIt took a long while to get here, but it was worth it. I have plans to release a Kindle edition at some point, but not immediately. The print edition always more popular historically. As any self-published author will tell you, it\u0026rsquo;s a team effort. I would like to thank everyone who helped make this possible. You know who you are.\u003c/p\u003e","title":"Email Deliverability Explained Second Edition"}]