Google/Yahoo 2024 Deliverability Guidelines¶

Spam rates and Gmail Postmaster Tools¶

Google says, "Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher" (emphasis ours). Gmail has blocked senders with a two-week average spam rate of 0.2%. Take Google at their word about 0.1% as the target rate, and assume ever reaching 0.3% will have consequences.

To watch spam rates, you must be signed up for Gmail Postmaster Tools. Unlike other ISPs, Google does not automatically report to ActionKit which users clicked Spam, or overall spam-click rates. Furthermore, Google and Yahoo calculate the percentage of active users getting your mail in the inbox who click Spam, so their rate will be higher than one calculated by ActionKit based on all recipients. Postmaster Tools is the only way to see your Gmail spam rates.

Before signing up, check a sent mailing from ActionKit to confirm what domain you send from. It might be your root domain, like example.org, or a subdomain like e.example.org or list.example.org, and it's important to get the exact domain. Otherwise, signup will probably complete without an error, but the stats in Postmaster Tools won't be the right ones!

Then, sign up for Gmail Postmaster Tools at postmaster.google.com:

Google will give you a DNS record to create to verify you own this domain:

To create this record, you need to know where your DNS is hosted, which might be where you bought the domain (Namecheap, GoDaddy, Hover, etc.) or a third-party DNS provider such as Cloudflare. If you're unsure, you can run an online DNS lookup and look through the results for a grey box saying "Your DNS hosting provider is [name]".

This record should go under the exact domain you mail from: if you send from e.example.org, you'll enter e as the record name, choose 'TXT' as the type, and paste in the string from Google as the value. If you have the option, you can set a low TTL (caching duration) for these records, like 600 or ten minutes, so that it's faster to make changes if something is wrong.

Once your domain is verified, you can click on it to see your top-level spam rates:

You can also go into "Feedback loops" where Google highlights particular days (and occasionally mailings) that had spam-rate trouble:

Postmaster Tools also lets you check SPF and DKIM compliance. Note it can show confusing false alarms, reporting 0% compliance on days no mail is sent, even though your setup is correct. Furthermore, because Gmail uses UTC time for reporting, you may see this on days that, in your own timezone, you did send mail. A mailing you send at, say, 9pm US Eastern on December 1st time is recorded by Postmaster Tools as sent on December 2nd in UTC.

When no mailings were recorded for a certain UTC day, you'll see these incorrect low numbers. Because your SPF and DKIM are backed by DNS records that don't often change, they don't actually fluctuate day-to-day. If you see a persistent 0% DKIM/SPF pass rate, contact us over Support so we can look into it.

Longer-term, ActionKit plans to build a Postmaster Tools integration, and Google has promised to add more details on compliance to the tools. For now, Google Postmaster Tools is only useful to you if you actively check your spam rates regularly.

Specifically, once you have Postmaster tools, we recommend routinely checking to see if you're under the 0.1% target and that you're safely clear of the 0.3% spam rate. You should also check whether any particular days or mailings show up in the Feedback Loops view. Be sure to check after any changes in your audience or mailstream, such as a burst of new users signing up or an outreach to a less-recently-active audience. It's also worth checking Postmaster Tools after you've sent more messages than usual, perhaps after a fundraising deadline or unusual news event.

As always, if you want advice about the setup process or something you see in Postmaster Tools, feel free to reach out to us over Support.

Checking your DNS setup at Gmail¶

Gmail makes its SPF, DKIM, and DMARC check results available for every message you receive in its "Show Original" view. If you have a Gmail address, you can send it a proof to quickly check if your ActionKit email passes its checks. First, just open or create a mailing draft and enter your Gmail address under 'Send Proofs':

Note that some organizations have multiple From domains set up in ActionKit, but only use one actively. Make sure you're sending from the same domain you use on real mailings. You can open a sent mailing to check, if needed.

Then, open your proof in Gmail. (It may take a few minutes, and if it doesn't arrive, check Spam; sometimes proofs go there even when your deliverability as a whole is OK.) Click the three vertical at the top right of the message and choose Show Original from the menu that pops up:

On the next page, you'll see a table, with "SPF", "DKIM", and "DMARC" as the last three rows. All rows should be present and say "PASS":

If there is no row for "DMARC" in the table, you should follow the steps from "Setting up a DMARC record" below. If any of the rows says "FAIL", or SPF or DKIM are missing, contact Support.

Setting up a basic DMARC record¶

These directions are for if you were shown a warning banner in your ActionKit instance saying you need to create a DMARC record, or you've otherwise confirmed there's a problem with your DMARC setup.

Warning

Please don't make these DNS changes if you didn't receive this warning or otherwise determine you're definitely missing a DMARC record. If you think something is wrong with your DMARC setup but aren't sure, contact us through Support with details.

Here's how to set up a non-enforcing DMARC record to comply with Gmail and Yahoo's February 2024 email sender guidelines.

Log into your DNS provider, which is often either where you bought the domain (Namecheap, GoDaddy, Network Solutions) or another service provider you use with your domain (Cloudflare or Google). If you're unsure, you can run an online DNS lookup and look through the results for a grey box saying "Your DNS hosting provider is [name]".

You need a DMARC record for any domain which appears in your "From" line. If your From line is Your Org <info@example.org>, example.org needs a DMARC record. For our example, let's say your From domain is example.org, not a subdomain such as list.example.org:

To make a basic DMARC record, you'll create a CNAME record named _dmarc pointing to basicdmarc.actionkit.com. Details of how to do this will vary by provider, but we'll use Cloudflare's process as an example. You can add a record at Cloudflare by clicking the example.org domain, choosing "DNS" in the sidebar, then "Records", then the "Add Record" button. You'll get a form you need to fill in like this:

Make sure to remember to pick CNAME in the dropdown, and note there's an underscore on _dmarc. Cloudflare's "Proxy status" option should be "DNS Only" (grey cloud) for this record. With other DNS providers, there will be no "Proxy status," and you can set any "TTL" field to 600 or leave the provider's default.

If your From lines use a subdomain like list.example.com or e.example.com, the steps are similar, except that the record name is _dmarc.list or _dmarc.e instead of _dmarc. This doesn't apply to most groups that need to add a DMARC record now.

Once you click Save on these changes, they typically take about an hour to take effect because of DNS caching. After an hour, follow the steps in "Checking your DNS setup at Gmail" above to see whether the change worked. If checks aren't passing an hour after you make the change, reach out to us on Support, and, if possible, include screenshots of your DNS provider's console showing the record you added.

DMARC is one aspect of complying with these guidelines; click through to our other guidance on Google/Yahoo 2024 Deliverability Guidelines for information on things like watching your spam rates.

Sidebar: understanding the DMARC change¶

The instructions above are all you need to get a compliant DMARC setup, but some people might have questions about what this change is doing, and why we're suggesting the specific records we're suggesting.

Note

This is not required reading for complying with the Google or Yahoo guidelines; we're only including it to help answer any questions you may have about DMARC and our suggested changes.

DMARC is an Internet standard for specifying how strictly you want ISPs to verify the origin of email that has your domain on the From line. If you have a strict DMARC record for example.org, then Gmail tries to verify that all mail from, say, info@example.org is really from you before putting it in the Inbox. They can verify mail one of two ways:

• SPF: Gmail verifies the IP the message was sent from by checking against a set of servers you specify via a DNS record.
• DKIM: Gmail verifies a signature in the headers of your message, by checking against a public key you specified in a DNS record.

When you first set ActionKit up, you create DNS records that allow ActionKit mail to be verified via SPF and DKIM. If you're currently sending ActionKit email from more than one domain (which we don't recommend), each of those domains needs SPF and DMARC records. If you also have Google Workspace or some other tool that sends email, it might have additional SPF and DKIM records for its mail.

What's new with these guidelines is that Gmail has decided to require that all bulk senders participate in DMARC. However, they do not require strict DMARC: you can create a permissive DMARC record that says "let mail through even if some can't be verified through SPF/DKIM".

The instructions above involving basicdmarc.actionkit.com help you create a permissive record. That's because most groups that need to add a DMARC record now are ones that send from their root domain (example.com not e.example.com). Root domains are frequently shared with tools other than ActionKit. For example, your root domain may also be used for your staff's outgoing email. We can't guarantee that your staff email, or other legitimate email you send from this domain, can be verified by SPF/DKIM. To avoid any risk of blocking your legitimate non-ActionKit mail, a permissive record is safest.

If you want to look into setting up a strict DMARC record, you can use a tool like dmarcian.com to see if it would block any desired mail. If you send from the root domain and use Cloudflare, Cloudflare DMARC Management (beta) can serve a similar function. If, after using either tool, you conclude it's safe for you to enable strict DMARC, you can implement their suggested DNS changes directly, or contact Support for help from us.

However, the permissive basicdmarc.actionkit.com record is a safe, quick route to complying with the Gmail/Yahoo guidelines, and what it's we recommend as the best choice for most organizations that need to add a DMARC record to comply with these guidelines.