How often should you rotate your DKIM key?

DKIM (DomainKeys Identified Mail) is a great process for authenticating email messages. It uses a public-private key pair to cryptographically sign an email message to ensure that it was not modified in transit and that it actually originated from somebody associated with the domain name used in the from address.

It's good stuff, and implementation is now relatively easy for most folks. ESPs support it, Google supports it, and you can do it with good ol' Postfix. But that's just setup -- what about ongoing maintenance? There's one thing you should be doing periodically, and that's updating your DKIM key pair, so that bad guys never have enough time to crack your DKIM key while it is still in use.

How often should you rotate (update) your DKIM key pair? Anti-abuse messaging industry group M3AAWG covers this in a whitepaper from 2019. And Proofpoint provides a concise summary of the same.

Too complicated? OK, fine. Rotate your DKIM key every six months. There. Easy, right? Let's say eventually bad guys figure out how to crack your key, putting in a couple of years hard work, maybe with assistance from a botnet or two. Six months is not so short a period that you are stuck updating keys constantly, but it's a quick enough interval that by the time somebody cracks that key it's been months or years since you actually used it to sign messages.

And make sure it's a 2048-bit key. A smaller key length isn't secure enough and a longer key length isn't certain to be supported by ISPs. Researchers broke a 768-bit key in 2010 with two years of work, and while a quantum computer could bust a 2048-bit key in 10 seconds, no such thing exists yet. So you're safe for now.

For some folks, implementing a 2048-bit DKIM key can be difficult, because the public key can be too long to fit into a single DNS text record. There's a solution to that; it's to break the TXT record up into chunks, as described here or here. If that's an insurmountable challenge, implement a 1024-bit key instead -- its public key will fit in a single DNS TXT record. That's better than not implementing DKIM at all -- lots of people still use 1024-bit keys. It's just not really forward looking, not future proof. Solve that problem tomorrow; your problem today is getting DKIM appropriately up and running.

TL;DR? Rotate your DKIM key every six months, and use a 2048-bit key if possible.

And don't do anything silly like try to rotate your DKIM keys daily or hourly. Email messages can get delayed in transit, and you need to have the key stable in DNS long enough for every possible ISP to receive and check the signature of that email message. After you stop using a key, it must remain alive at least long enough to account for its use by all messages already in transit, until they are delivered. I would assume that'd be 3-4 days, but I don't see any hard data on this and I think it unwise to proceed on assumptions alone.

What IP address sent me that email message?

Every email server has an IP address. It's sort of like the phone number for a server. It's often a stable identifier. Each IP address traces back to a company who owns a particular "network" or "block" of IP addresses. The IP address likely also references a domain name that may be the email platform, or may reference the brand that is emailing you. Often "big" email senders will have dedicated IP addresses (IP addresses meant only for their use), while "small" email senders may share an IP address or group (pool) of IP addresses with other small email senders.

(Geek break: When you see email people, especially deliverability people, talking about IP addresses, we're referring to IPv4 IP addresses, not IPv6. Sending email over IPv6 has yet to be universally adopted for email sending and while it does exist, it's outside the scope of what I'm discussing today.)

That sending IP address is stored in hidden email headers, primarily the "Received" email headers. There are multiple ways to access it:
  1. The first easy way: In Gmail, when you select "Show Original" to view the full headers and email source, Gmail shows you a series of bits of information about the email message, right at the top:
    See where it says SPF: PASS with IP address XXX. There's your sending IP address.
  2. The second easy way: The "Received-SPF" or "Authentication Results" header. For example, in Microsoft, select "Message Source" (or select "View Raw Message" in Yahoo Mail) and look for "Received-SPF: Pass (domain of XXX designates YYY as permitted sender)." In that instance, YYY is your sending IP address.
  3. The third easy way: Look for the "X-Originating-IP" header. This is viewable in Yahoo Mail when selecting "View Raw Message" and shown by some other ISPs as well. The value it gives you there, inbetween [brackets], is the sending IP address.
  4. The harder way. View full source for an email message, look for the "Received" headers and review them. You start from the bottom and work your way up. You're looking for the first or second bottommost received header. You're looking for the first reference to the ISP's mail server. Received from (server name) (IP address) by (something) if it's Microsoft Hotmail/ Received from (server name) (IP address) by (something) or (something) if Yahoo Mail or Gmail.
    In this case, the sending IP address is This is the lowest received header that mentions the receiving ISP (, so it's showing what server connected to the ISP to deliver this email message, and there's the IP address.
Huge caveat: If your're doing this for corporate email, and if your company uses certain types of spam filtering, like, for example Proofpoint, the first three IP address identification methods might not work. My work, for example, uses Proofpoint, with servers in the domain name In that case, to find the sending IP address, I can't trust the SPF results headers, and there's no Originating-IP header to reference. So, I need to look for that lowest (or second lowest) received header that says that server XXX at IP address YYY handed the mail off to Proofpoint's servers at This is important -- if you get this bit wrong, you'll end up reporting spam to the wrong place. So look "beyond" what server handed the mail off to the ISP and look for what server handed it off to your spam filter's server. (I know, I know. This is a very brief explanation for a complex issue, and I apologize for that. But we've got to start somewhere.) If you're not sure if your company uses a spam filtering service in this way, you might want to ask your IT people for guidance. And know that this is almost never the case for non-corporate mail. If you're looking to report spam for mail you you received in your personal Gmail, or or Yahoo Mail account, you won't run into this issue.

Now that you know the sending IP address, here's what you can do with that information.
  • You could plug in the IP address on my XNND website and click on the "Did you receive spam from XXX?" link. If the website suggests an address to send to, that's where you'd email a spam report to. (Don't report spam to; that's the Proofpoint spam filter, not a spam source. If the IP address you're checking has a hostname that ends in, you're probably not looking at the right IP address.)
  • You could look up the IP address ownership info using the right Regional Internet Registry. This ownership info likely contains a company name and likely even contains a spam (abuse) reporting address. There are five RIRs (APNIC for Asia-Pacific, ARIN for North America, RIPE NCC for Europe, LACNIC for Latin America/Caribbean, and AFRINIC for Africa). My XNND tool can usually figure out which RIR is the right one and will give you a link to "query" the IP address in the appropriate registry. Click through, look at the contact info, see if there's an "abuse" contact, and then you can email your spam report to that address. 
  • You could go look up the Sender Score of the IP address and if that score is low, you're probably not the only person receiving spam from that IP address.
  • If you run a spam filter or blocking list, you could add this IP address to that list, if you want to reject future mail from this server, on the theory that where one spam came, more are likely to follow.
And that's where I'll wrap it up today. This might seem a bit incomplete, but I'm working through different sub-topics here with a goal of leading to a single, linked guide to all of these different steps involved with tracing email messages and sending spam complaints. Stay tuned for more and thanks for reading!

Help! I'm blocked at Microsoft! What do I do?

Keep in mind that Microsoft has two separate mail systems: OLC (Outlook Consumer) which you might call Hotmail, and corporate mail hosting, the mail systems associated with their Office 365 service. The two systems have separate processes with regard to requesting to be unblocked. Here's links for both.

Microsoft OLC: If you are trying to send mail to,,, or any other Microsoft OLC (Outlook Consumer) domain and you're seeing this bounce message:

5.7.1 (delivery not authorized) Unfortunately, messages from [] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to []"

Or if you are seeing this deferral/delay message:

451 4.7.650 The mail server [] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see (S843) []

Then you've got a reputation issue at Microsoft OLC (Hotmail/ to address. Why? What caused it? Multiple things can make this happen. A few of the possible reasons are: Too many complaints. A spike in email send volume. Too many attempted deliveries to invalid addresses (which can appear to Microsoft to be a dictionary attack). Too many negative SRD votes. And possibly other things. You might want to engage a deliverability consultant to review your email marketing methodology and data to identify any possible issues. 

When you're ready to reach out to Microsoft (OLC) to request that they either stop blocking you or that they should allow you to send more mail to their users, you'll want to go here and fill out this form.

For more guidance and understanding around blocking issues and deliverability best practices fo Microsoft OLC (Hotmail), click here for my Microsoft OLC ISP Deliverability Guide. Microsoft also publishes a Postmaster Site for, though some of the info looks as though it may possibly be out of date.

Microsoft Office 365: If you're trying to send email to corporate domains that are hosted by Microsoft and you're seeing this bounce message:

5.7.606 (undefined status) Access denied, banned sending IP []. To request removal from this list please visit and follow the directions. For more information please go to AS(1430) []"

Then you've got a reputation issue at Microsoft Office 365, the corporate mail hosting side of things. That's different than Hotmail. Both systems run on the same back-end platform, but it's not clear to me if the spam filters are exactly the same-- I suspect they are not. Generally speaking, the same kinds of sending issues can cause blocking on either side, but I have my doubts that the thresholds and mechanisms and monitors would be exactly the same.

When you're ready to reach out to Microsoft (Office 365) to request that they stop blocking you, you'll want to go here and fill out this form.

Sergey Syerkin, Head of Email Delivery Operations at MailerQ was kind enough to share this additional information for Microsoft Office 365: If you're having a content-related issue and/or a high "SCL" (Spam Confidence Level) issue with Office 365, you may need to utilize the false positive submission process documented here. Thanks, Sergey!

Gmail spam filters don't know what party you represent

I don't think there's actually a conspiracy to block the political email messages of any certain party. I see no clear data suggesting political bias in spam filtering decisions. So where did this idea come from? Representative Greg Steube (R-Florida) complained to Google's CEO last week that his campaign emails going to the Gmail spam folder and how that this is supposedly happening only to Republicans. Groan. Not true. Mail is filtered based on whether or not the mechanisms the ISPs have in place can identify it as wanted or unwanted. It's that simple. Yes, those filters are complex. Yes, they are possibly even imperfect. No, they are not out to get you.

The real issue is that, "by and large, political senders are simply not great senders," and Nicky Copland from Validity explains why. Spam is spam. Spam is unwanted, and ISP spam filters try hard to keep unwanted mail out of view. And political senders aren't exempt.

In spite of what Rep. Steube claims, the data collected by the Markup back in March shows that political senders from both parties can end up in the spam folder. Affected Democrats included Beto O'Rourke, Kamala Harris and Andrew Yang. And let's not forget Tulsi Gabbard's lawsuit against Google last year. It has since been dismissed, but one of the suit's allegations was that Gabbard's emails were being placed in spam folders on Gmail at “a disproportionately high rate” when compared with emails from other Democratic candidates.

In short, Democrats get blocked, too. And like Nicky Copland says, any blocking, affecting someone affiliated with either main party, is very likely due to send practices, not due to their political viewpoint. If I were to suspect some commonality in a group of senders all going to the spam folder, I know from experience that the common thread is probably similar (poor) sending practices. It could in theory be due to something else, but there's no compelling data suggesting so. 

The Markup missed the boat in their coverage, seemingly not touching on or showing an understanding of what email reputation is and how spam filters work. And their dataset was limited -- it covered only 2020 presidential candidates, but I think it's enough data to show the (lack of a) conspiracy.

And this kind of misunderstanding of how spam filters work -- looking for a conspiracy where none is to be found, is hardly new. Remember

Top 10 Email Security Blogs...from 2010

Check out this list of top ten email/security blogs from November 2010. You know which URLs still resolve? Which ones are clearly still here? Only three of the ten.*
All three of us practically came up from the same streets, in a sort of way. Working to deal with and stop spam on our own in the late 1990s. which led to working for a blocking list/abuse desk provider in the early naughts -- and surviving that crazy, broken working environment. And then moving upward and onward from there, growing into our careers focused on deliverability, email technology and policy compliance. And all three of us are still sharing our knowledge and expertise with clients and with the world through our websites.

That's pretty amazing, if I do say so myself. The web often melts into a bowl full of broken links over time, but not in this case. We're still here. We're still doing the work, ten years after that was posted! The rest of those sites listed, the domains are dead or for sale, the blogs haven't been updated in years, or they have otherwise been shut down or abandoned. Even the blog that original posted the list, Email Security Matters, was retired and the content moved into the website of its corporate owner Vircom sometime circa 2013.

* Honorable mention: Richi Jennings is still out there blogging, but I might say it doesn't qualify, based on a bit of a technicality, as he has a new site at a slightly different domain name. I'm sure some of the others might still be out there too (Kevin Townsend appears to be writing for Security Week), but Richi's is the only other one with even a hint of continuity from then until now.

GMX and to offer Deutsche Post Informed Delivery-style Service

If you live in the US, maybe you've already heard of the Informed Delivery email service from the USPS (United States Postal Service). It provides you a daily email digest previewing postal mail letters and package information just before they get delivered to you. It helps you know when and what mail is coming, and it can potentially help you identify when mail has gone missing. It even includes a scanned image of the front of (most) incoming mail pieces. It's pretty useful, and I highly recommend it. If you haven't already subscribed, go here to sign up.

And today I see an announcement from a large German mailbox provider offering a similar service for residents of the Federal Republic of Germany. Deutsche Post is working with 1&1 (GMX and to start this new letter announcements service. 

Small Mailserver Best Current Practices

Phil Pennock is an email administrator, software engineer and one of the maintainers of the open source Exim MTA (mail transfer agent; aka mail server) and after a recent discussion on the Mailop list, he put together a good list of considerations/best practices for administrators of small mail servers wanting to maximize their chances of being able to send email messages successfully to users at Gmail (and the world).