If you want to improve your deliverability and email marketing performance, you have to track, measure, and optimize your emails.

Monitoring key deliverability metrics is important because it allows you to react to things that can impact your email deliverability, like a high spam complaint rate.

Higher email deliverability = more people reached = higher ROI on your emails.

One of the essential tools in email deliverability is Google Postmaster Tools. It contains data straight from Gmail, making it the most accurate source for metrics like complaint rates.

What is Google Postmaster Tools?

Google Postmaster Tools is a free tool from Google that gives you access to your email performance and reputation data. Their data includes gmail.com, googlemail.com, and paid Google Workspace addresses.

It’s worth signing up even if Gmail isn’t your primary target. Understanding how Google perceives your emails can help you understand how other ISPs like Microsoft see them.

For privacy reasons, data will only show if you’re sending enough emails to Google inboxes. Google doesn’t publish the threshold, but it seems to be upwards of around 300 emails per day to Google recipients.

How to sign up for Google Postmaster Tools

To use Google Postmaster Tools, you’ll first need a Google account.

Then, Sign up or log in to Google Postmaster with your Google account. After selecting Get Started, you’ll be asked to add your domain.

Select Next, and you’ll be asked to verify your domain ownership.

Log into your DNS provider (like GoDaddy or Namecheap) and add the TXT record provided, then go back to Google Postmaster and click on Verify. Once the record is properly published and Google can find it, you’ll see the domain status change to Verified.

That’s it. Don’t later remove the DNS record you added, or you’ll lose the verification status.

Google Postmaster Tools deliverability metrics to monitor (and how)

To get started with deliverability monitoring, you’ll need to track these:

• Spam complaint rate
• IP reputation
• Domain reputation
• Authentication success rate
• Delivery errors

Spam complaint rate

The spam rate is the percentage of emails marked as spam by users versus emails sent to the inbox. This metric becomes even more important in 2024 when Google starts to require a spam rate of less than 0.3%.

While useful, the spam rate doesn’t provide the full picture. That’s because it specifically refers to spam complaints. You could see a low spam rate even if your emails are being delivered directly to spam — people can’t complain about your emails if they don’t see them.

IP reputation

IP reputation is how emails originating from your sending IP are perceived. A higher IP reputation means emails from this IP are more likely to reach inboxes. A low IP reputation can result in your emails being sent directly to spam.

Google Postmaster Tools splits IP reputation into four categories. The definition of spam here includes email reported by users as spam (this is the spam complaints metric mentioned above) and email detected by Gmail’s spam filter.  

• Bad: A history of sending a high volume of spam. Mail from this IP will almost always be rejected or marked as spam.
• Low: Known to send a considerable volume of spam. Mail from this IP will likely be marked as spam.
• Medium/Fair: Known to send good email, but has occasionally sent a low volume of spam. Most email from this IP will have a fair deliverability rate unless there’s a significant increase in spam levels.
• High: A good track record of a very low spam rate, and complies with Gmail’s sender guidelines. Mail will rarely be marked by the spam filter.

If you’re using a shared IP address like most people, your IP reputation is also shared among everyone sending from that IP. That’s why it’s important to pick a reputable email service provider that doesn’t allow spammers.

Domain reputation

Like IP reputation, domain reputation is how emails from your sending domain are perceived.

• Bad: A history of sending a high volume of spam. Mail from this domain will almost always be rejected or marked as spam.
• Low: Known to send a considerable volume of spam. Mail from this domain will likely be marked as spam.
• Medium/Fair: Known to send good email, but has occasionally sent a low volume of spam. Most email from this domain will have a fair deliverability rate unless there’s a significant increase in spam levels.
• High: A good track record of a very low spam rate, and complies with Gmail’s sender guidelines. Mail will rarely be marked by the spam filter.

Domain reputation within GPT refers only to the domain you use to send emails, like acme.com or newsletters.acme.com. However, though individual subdomains carry their own reputation, they do also share in the reputational pool of the primary domain and other subdomains so it is a good idea to make sure all are reported on.

Authentication success rate

Email authentication refers to your SPF, DKIM, and DMARC. Properly authenticated emails is an indicator of non-spam email, and in 2024 DMARC compliance is required by Google.

A high authentication success rate means your emails are secured and passing authentication tests, which can help improve deliverability.

Google Postmaster Tools shows the percentage of emails that passed SPF, DKIM, and DMARC over all received emails that attempted authentication.

• SPF graph: the percentage of emails that passed SPF versus all email from your domain that attempted SPF.
• DKIM graph: the percentage of emails that passed DKIM versus all email from your domain that attempted DKIM.
• DMARC graph: the percentage of emails that passed DMARC alignment versus all email received from your domain that passed either SPF or DKIM.
  

Delivery errors

Delivery errors tell you why your emails aren’t being delivered. Google Postmaster Tools shows what percentage of your total emails were rejected or temporarily failed as compared to all authentic traffic.

• Rate limit exceeded: your domain or IP is sending at a suspiciously high rate and you’ve been temporarily limited.
• Suspected spam: your email is suspected to be spam by Google.
• Email content is possibly spammy: your email is suspected to be spam, but specifically because of its content. In this case, you can use SendForensics to analyze your email content for spam triggers.
• Bad or unsupported attachment: your email contains attachments not supported by Gmail, like .bat or .exe.
• DMARC policy of the sender domain: your DMARC policy is reject and this email failed DMARC.
• Sending IP has a low reputation: your IP reputation is very low.
• Sending domain has a low reputation: your domain reputation is very low.
• IP is in one or more public RBLs: your IP is listed on a real-time blackhole list.
• Domain is in one or more public RBLS: your domain is listed on a real-time blackhole list.
• Bad or missing PTR record: your IP is missing a DNS pointer (PTR) record.

Ideally you won’t run into any delivery errors — but if you do, this is a starting point for troubleshooting.  You can then use a tool like SendForensics to analyze the emails for the source of these issues.

Encryption

The encryption dashboard shows what percentage of your inbound and outbound traffic is TLS encrypted.

If your email system is set up for TLS, it will attempt to negotiate TLS encryption with every server you send to or receive from. Emails sent using a non-TLS connection to an account that’s expecting encryption will likely be rejected.

Your encryption pass rate should always be 100%. If it isn’t, contact your email service provider.

Feedback Loop (FBL)

There’s another graph Google Postmaster Tools offers: the feedback loop. ISPs use feedback loops to tell senders about spam complaints.

Gmail’s feedback loop is only available to email service providers. It’s an aggregated FBL, so reports are rolled up into identifiers you define in the Feedback-ID header.

If you’re not an ESP, you can’t access this data.

Final thoughts

Sender reputation is a core part of email deliverability. There’s a lot you can do with GPT, but there’s some parts of deliverability monitoring only premium deliverability tools can do:

• Deliverability analysis. A premium deliverability tool analyzes your entire email and sending infrastructure for problems. Optimizing emails is easier when you can see what content looks spammy, and you can troubleshoot delivery errors like missing PTR records.
• DMARC monitoring. With a platform like SendForensics’ DMARC monitoring, you can troubleshoot emails that failed DMARC tests and see how to fix it.
• Alerts. Google Postmaster Tools doesn’t let you know if there’s a problem. Platforms like SendForensics monitor your GPT data in the background and send you notifications when there’s a reputation issue.

SendForensics integrates directly with Google Postmaster Tools. See your GPT data directly in SendForensics next to other reputation signals like campaign performance, and use alerts to monitor your reputation and get notified when something goes wrong.

There's only a couple days left until Yahoo and Google are due to begin rolling out their new bulk sender updates. Emails that don't comply with the new updates may start seeing higher rejection and spam placement rates.

A lot is changing, but if you're late to the game or strapped for time, these are arguably the two most important changes to implement:

• Basic DMARC compliance (if you send >5,000 emails per day)
• Keeping your spam complaint rate under 0.3% (regardless of sending volume)

Read on for two very quick help snippets. You might be closer to compliance than you think!

Making sure emails are DMARC authenticated

If you're not sure where to start, here's a flowchart to help.

Google and Yahoo will now start requiring DMARC authentication for higher-volume senders. However, for this update a p=none policy is enough for basic compliance without disruption — though we recommend eventually moving to a quarantine policy.

If that means nothing to you, this article should make you a casual expert in no time:

Beginner’s Guide to DMARC (2023)

DMARC secures your email from spoofing. Learn how DMARC works with example policies and reports from Stripe and Amazon.

SendForensics BlogDee Mirai

If you're already passing SPF and DKIM, then DMARC compliance is probably not far away. And if you're already using SendForensics, you can simply log in and upload our starter DMARC record to your DNS provider.

Your next email analyses will likely show compliance and you'll start seeing real-world compliance data within 48 hours to prove it. Alternatively, read the following guide for self-implementation:

How to Implement DMARC (Step-by-step Guide)

Not sure how to set up DMARC? Follow this step-by-step guide to upload a basic DMARC policy and start receiving aggregate reports.

SendForensics BlogLeo Hatton

Sign up for Google Postmaster Tools

Your spam complaint rate must remain below 0.3% if you send more than 5,000 emails per day to Gmail inboxes. This threshold is based on the number of people who receive your emails and manually report them as spam — not when your email actually lands in spam (if it isn't being seen, it can't be complained about!).

Google Postmaster Tools is completely free and monitors your sending reputation with Gmail, which includes providing the all-important complaint rate metric. Keep a constant watch for signs of approaching the 0.3% threshold so action can be taken pre-emptively.

If you're a SendForensics user, you can integrate natively with Google Postmaster Tools to track complaint rates in your Reputation dashboard along with other email metrics. This way, you can also set alerts to get notified the moment your complaint rate approaches the threshold.

In February 2024, both Yahoo and Google will be releasing a major update that affects how you send email to Gmail and Yahoo/AOL inboxes. These new requirements affect free Gmail accounts, Google Workspace accounts, Yahoo Mail, and AOL.

Here's how Google described the update in their announcement:

Starting in 2024, we’ll require bulk senders to authenticate their emails, allow for easy unsubscription and stay under a reported spam threshold.

There are two sets of requirements for bulk senders: senders who send less than 5,000 emails per day to Gmail/Workspace inboxes, and those who send more. Here's what they'll require from all bulk senders:

• Set up SPF or DKIM authentication
• Ensure that sending domains and their respective sending IPs have valid forward and reverse DNS records
• Keep spam rates reported in Google Postmaster Tools below 0.3%
• Format messages according to the Internet Message Format standard (RFC 5322)
• Don't impersonate Gmail From: headers
• If you regularly forward email, add ARC headers to outgoing email

And if you send more than 5,000 emails per day, you also need to:

• Set up SPF and DKIM authentication
• Set up DMARC authentication and pass DMARC alignment
• Enable one-click unsubscribe with a clearly visible unsubscribe link

Note: while this article refers to Google, Yahoo’s requirements are stated to be the same.

When do I have to comply with the Google changes?

The update will be released February 1st, 2024. If you currently send over 5,000 emails per day to Gmail accounts, Google recommends working on these changes immediately.

To prevent potential deliverability problems in February, you should start looking at how to fulfil these requirements now.

What are the new requirements for sending to Gmail accounts?

1. Set up SPF and/or DKIM authentication

SPF and DKIM are two core email authentication methods. Not only do SPF and DKIM protect your emails individually, but they’re also needed for DMARC.

2. Have valid forward and reverse DNS records

Your sending domain and its respective sending IP(s) must have valid forward and reverse DNS records (also called PTR records). PTR records verify that the sending hostname is associated with the sending IP address.

You probably already have a valid forward DNS record, but you might need to set up a reverse DNS record if it hasn't already been done for you by an ESP (especially if you are using a dedicated IP). See your forward and reverse DNS records and test results in SendForensics' infrastructure analysis:

If both rDNS tests pass, your PTR record is valid. You can also check your PTR record with Google's Dig tool.

3. Keep your Google Postmaster Tools spam rate below 0.3%

Google Postmaster Tools is a free tool that monitors your Google reputation. If you’re already exceeding a 0.3% spam rate regularly, you’re probably already seeing some deliverability issues. Once the changes kick in, this will get worse.

Monitor your Google Postmaster Tools reports regularly, or integrate it with SendForensics to get alerts on your spam rate and other problematic thresholds.

3. Don't impersonate Gmail From: headers

In February, Google will begin enforcing a DMARC quarantine policy on at least gmail.com and googlemail.com email addresses. So if you send business emails using a @gmail.com email address from a sending system other than Gmail itself, these emails will very likely end up in spam (if they don't already).

If you send business emails using a @gmail.com email address, this is one more reason (of many) to switch to your own domain.

4. If you regularly forward email, add ARC headers to outgoing email

This is mostly applicable to receivers such as inbox providers, ISPs and the like, when they forward email to other destinations.

Authentic Received Chain (ARC) checks the previous email authentication results of forwarded emails. Without it, forwarded emails can result in authentication failures.

If a forwarded message passes SPF or DKIM authentication, but ARC shows it previously failed authentication, Gmail treats the message as unauthenticated.

5. Comply with DMARC authentication

Starting February, DMARC authentication is mandatory if you send over 5,000 emails per day to Gmail accounts and recommended even if you don't. Messages that aren't authenticated might be marked as spam or rejected with a 5.7.26 error.

While it is possible to implement and monitor DMARC on your own, the easiest way to get started with DMARC is using a tool like SendForensics.

Google only requires DMARC compliance, not a specific policy. p=none is enough to meet this requirement as long as your emails are DMARC compliant (though you should still look at upgrading to p=quarantine or p=reject eventually).

The topic of DMARC could be several articles on its own. Check out our beginner’s guide to DMARC, or this step-by-step guide to implementing DMARC.

6. Make sure the domain in your From: header is aligned with either the SPF or DKIM domain

This is required to pass DMARC alignment and become DMARC compliant.

While smaller senders technically only need to implement one of SPF or DKIM, this alignment requirement is why we recommend implementing both. If SPF alignment fails for whatever reason, at least you can fall back on DKIM alignment. When using an email service provider, this often means adding a second DKIM signature with your custom domain.

7. Support one-click unsubscribe and include a clearly visible unsubscribe link

If you send over 5,000 emails a day to Gmail accounts, marketing messages and subscribed messages must support one-click unsubscribe.

Your email service provider should handle this for you, so contact them for more information. If you manage your own email, add both of these headers in outgoing messages:

• List-Unsubscribe-Post: List-Unsubscribe=One-Click
• List-Unsubscribe: <https://acme.com/unsubscribe/example>

These are RFC 8058 and RFC 2369 respectively.

Your emails should already include a clear unsubscribe link that leads to a page that makes it easy for recipients to unsubscribe from all mail.

Some senders use a preferences center to let people choose what kind of messages they want to receive. In this case, you must also separately allow people to unsubscribe from all emails in one step.

Is there anything else I have to do?

Google has published a few other, smaller requirements.

• Format messages according to the Internet Format Standard (RFC 5322)
• Don't use HTML and CSS to hide content in your messages

An email testing platform like SendForensics can highlight issues with these requirements.

You can see the full list of requirements on Google support.

Special considerations for email service providers

If you're an ESP, you should:

• Provide an email address for reporting email abuse
• Make sure your contact information on your WHOIS record and on abuse.net is current
• Immediate remove any client using your service to send spam

SendForensics can help you automatically detect clients sending problematic emails before the emails leave your network. Contact us here for more information.

Additional resources

• "New Gmail protections for a safer, less spammy inbox", Google
• "Email sender guidelines", Google
• “More Secure, Less Spam: Enforcing Email Standards for a Better Experience”, Yahoo
• “Sender Best Practices”, Yahoo
• "New minimum requirements for sending bulk email to Gmail and Yahoo", M3AAWG

Today, we're introducing an improved hierarchical layout with new sender discovery features that puts your domain at the center of deliverability.

Very few companies are aware of the true extent of their outbound email footprint, like how many different systems are sending from how many different sending domains. But why is it so important?

A large part of deliverability is your sender reputation: how inbox providers view you as a sender, based on your emails received over time. Sender reputation is made up of both domain and IP-based reputation. In recent years, domain-centric reputation has largely superseded IP reputation. This is because IPs are easy to change, but your brand’s primary domain is not.

The challenge with domains

All websites start with the primary domain. This is the main URL for your website, like acme.com. This could also be the only domain used for email, or one of many:

• You might use Microsoft 365 for your business email, sending from acme.com
• You might use Salesforce for your CRM, also sending from acme.com
• You might use Zendesk for customer support, sending emails from helpdesk.acme.com
• You might use Mailchimp for marketing campaigns, sending from offers.acme.com
• Transactional emails like order receipts and alerts could be sent from notifications.acme.comx

Collectively, these are called sending domains: any domain you send an email from.

Many businesses use subdomains to isolate email activity and prevent reputation problems from cascading. The theory goes that if something goes wrong with your marketing subdomain, you don't want it to block critical transactional emails like password resets from sending.

Subdomains can mitigate against potential damage, but it is not foolproof — if it were, spammers would just use new subdomains. If too many subdomains have a bad reputation, your primary domain will be impacted.

“The risk is that "maindomain.com" may get filtered if too many subdomains look bad, but that needs to be a risk you accept and manage by maintaining the reputation of all subdomains.”  via Spamhaus

As your business grows, you'll likely end up with lots of domains. Some common scenarios:

• A domain for each country: acme.com, acme.fr, acme.br...
• A subdomain for each email activity: news.acme.com, help.acme.com...
• A combination of both: acme.com + secure.acme.com, acme.com + ensecurite.acme.fr

This heady mixture of sending systems, domains and subdomains simultaneously hold their own reputation, contribute to each others’, and impact the overall reputation of the primary domain.

The more complex your domain tree, the harder it is to measure and test deliverability, as no sending domain or sending system should be left out.

SendForensics' new layout

Our improved navigation focuses on the primary domain as a first-order principle. To reflect the impact each sending domain has on overall deliverability as well as its own, all sending domains are shown within a primary domain.

Each SendForensics account can have multiple primary domains:

And each primary domain can have multiple sending domains:

This is a more accurate reflection of how deliverability works across primary domains and sending domains.

Get started

To get started, simply log in to SendForensics or sign up for a trial. You'll see the new look immediately, as well as any automatically identified domains.

In this tutorial, you'll be editing your domain's DNS records to add a DMARC record. Before you start, make sure you have either SPF or DKIM set up and passing. DMARC will not work without at least one of these.

You'll also need access to your domain's DNS, which is usually provided by your registrar (like Godaddy or Google Domains).

Step 1. Add a DMARC record to your DNS

The record we usually recommend starting with has a "monitor" policy.

v=DMARC1; p=none; rua=mailto:[reportingemail@yourdomain.com]

This has a p=none policy, so emails won't be rejected or sent to spam if DMARC fails. All it does is forward rua reports to your email address. You may also find that simply adding a DMARC record achieves DMARC compliance for your emails, if either SPF or DKIM have been set up correctly.

Within your domain's DNS, add the following DNS TXT record:

Replace [reportingemail@yourdomain.com] with the email you want DMARC reports to be sent to. We recommend setting up a separate inbox for this (like dmarc@yourdomain.com) so your primary email doesn't get flooded with reports.

Reports can also be sent to multiple emails with a comma separator:

rua=mailto:rua-import-xxx@sendforensics.com,mailto:hey@mydomain.com

Note that if the email receiving reports is on a different domain, an additional DMARC authorization record needs to be in place within that external domain's DNS.

You can also add a ruf reporting address for individual forensic reports, but most people don't need this.

Step 2. Check your DMARC reports

It can take up to 48 hours for DNS to propagate and to start receiving aggregate reports. Reports are usually sent daily, though this varies by provider.

DMARC reports are sent as raw XML files. You can use a DMARC monitoring tool like SendForensics, or read them yourself.

<record>
	<row>
		<source_ip>203.0.113.209</source_ip>
			<count>2</count>
		<policy_evaluated>
			<disposition>none</disposition>
			<dkim>pass</dkim>
			<spf>pass</spf>
		</policy_evaluated>
	</row>
	<identifiers>
		<header_from>mydomain.com</header_from>
	</identifiers>
	<auth_results>
		<dkim>
			<domain>mydomain.com</domain>
			<result>pass</result>
			<human_result></human_result>
			</dkim>
		<spf>
			<domain>mydomain.com</domain>
			<result>pass</result>
		</spf>
	</auth_results>
</record>

Verify authentication results are pass:

<auth_results>
		<dkim>
			<domain>mydomain.com</domain>
			<result>pass</result>
		</dkim>
		<spf>
			<domain>mydomain.com</domain>
			<result>pass</result>
		</spf>
</auth_results> 

Check alignment by matching the domain with the header_from.

<identifiers>
  <header_from>mydomain.com</header_from>
</identifiers>

DMARC will pass if either:

SPF passes and the SPF domain matches the header_from domain, or

DKIM passes and the DKIM domain matches the header_from domain

Step 3. Fix DMARC failures

DMARC fails when neither SPF nor DKIM is aligned. It doesn't matter if SPF/DKIM passed individually - one of them must also align (their domain matches with the header_from).

Only move on to the next step when you've confirmed:

1. You're receiving aggregate reports on schedule
2. DMARC is passing consistently across all your sending systems using that domain (marketing, business email, transactionals etc)

Step 4. Enforce DMARC

Once you're confident DMARC is passing consistently for all your sending systems using the domain, you can start enforcing a stricter policy and instructing receiving servers what to do with emails that fail.

From here, your specific policy depends on how aggressive you want to be. We usually recommend a phased approach; initially using quarantine to minimise any accidental loss of legitimate email, monitoring again for a period, then moving to a stricter reject policy which protects against spoofing better.

Some organizations have dedicated subdomains for specific email channels/sending-systems, like e.economist.com or notif.salesforce.com. If you have a dedicated subdomain like this, always send from the same provider, and the subdomain has its own DMARC record, then moving to a reject policy is low risk.

You can also start adding the optional tags to customize DMARC enforcement. Common ones are pct for the percentage of failed emails the policy should apply to, adkim and aspf for stricter alignment (default is relaxed), and ruf if you want forensic reports.

In 2010, engineers from 17 organizations (including Google, Paypal, LinkedIn, and Microsoft) met to discuss combating spam, especially the increasing spoofing/counterfeit varieties, at scale. After several drafts, DMARC was released in 2015 as RFC 7489.

Uptake was slow, like it usually is with new standards. However, by 2021, there were nearly 5 million valid DMARC policies.

What is DMARC?

DMARC (technically Domain-based Message Authentication, Reporting, and Conformance, but that's a mouthful) extends the existing SPF and DKIM standards. At its core, DMARC is two things in one:

1. It's an email authentication protocol that verifies emails are actually coming from the domain they claim to be coming from
2. It's a reporting system that tells you when your emails fail DMARC authentication (in other words: they might be spoofed)

Why do you need DMARC?

In 2013, Facebook and Googles employees received an invoice from Quanta Computer, a Taiwan-based computer hardware manufacturer. The invoices seemed normal — they'd done business with Quanta Computer before — so they transferred the amount due and moved on.

Except the invoices didn't exist. These emails weren't from Quanta Computer at all, but a spoofer named Evaldas Rimasauskas. His fake emails looked like they came from legitimate Quanta employees. Facebook and Google lost over $100 million before the scam was found.

In this attack, the only affected parties were Facebook and Google. That's not always true.

The 2017 Amazon Locky attack targeted Amazon customers by spoofing real shipping updates sent from auto-shipping@amazon.com. The only content in the email was a Microsoft Word file. Anybody who downloaded it would find their device locked with a $250-$500 ransom.

DMARC's primary purpose is to stop people from spoofing your email address. However, by raising the level of trust in emails from your domain, it also indirectly helps your email deliverability. Properly configured SPF/DKIM and DMARC records are signals of good sender behavior, and can improve your sender reputation.

How does DMARC work?

Unlike SPF and DKIM, which are both self-contained, DMARC has to piggyback off either SPF or DKIM for it to function.

A DMARC test will pass if either SPF or DKIM passes and that pass is aligned.

DMARC enforces alignment between either the SMTP MAIL FROM domain (SPF domain) and the FROM header domain, or the domain on a DKIM signature and the FROM header domain. In both cases, think of the FROM header domain as the anchor.

If the email passes the receiving server's DMARC test, it's a big tick for that email's trust profile and it'll likely be treated favourably.

If the email fails the DMARC test, the receiving server looks at the domain's DMARC record to help it decide what to do with the failed email. The policy tag in that record tells it to either do nothing, quarantine the email, or reject it completely. It may also ignore the tag completely and do its own thing, but that particular behaviour is in the minority.

If there is a reporting address in the DMARC record, the receiving server also sends a report of the email transaction as an aggregate (rua) DMARC report.

What does a DMARC record look like?

Let's look at the DMARC record for Stripe for example. You can see it for yourself by doing a standard DNS lookup of  _dmarc.stripe.com:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@stripe.com; ruf=mailto:dmarc-forensics@stripe.com

We'll break down each component in this record.

v=DMARC1

This is the DMARC version and serves as an identifier to receiving servers. It's a required tag, and if it's missing or incorrect, the DMARC test will be skipped.

p=reject

Stripe has decided to implement a reject policy, instructing receiving servers to reject all emails that fail DMARC. Some servers may ignore this instruction, but most will follow it.

rua=mailto:dmarc-reports@stripe.com

Email providers send aggregated reports to this address about all emails they've received from Stripe's domain. The reports are high-level and anonymized, containing no personally identifiable information.

For privacy reasons, most DMARC monitoring tools (including SendForensics) will only accept rua reports.

ruf=mailto:dmarc-forensics@stripe.com

Stripe also has a different email address for forensic reports. These are individual forensic failure reports that will be sent in real-time, including specific details about the failure.

Optional DMARC tags

There's a number of optional DMARC tags you can use to fine-tune your policy.

Stripe's full DMARC policy contains two of these optional tags: pct=100, meaning 100% of failing emails should be rejected (the default setting i.e. this tag can also be left out of the record), and fo=1, meaning to send a forensic report if any test (SPF, DKIM, or DMARC) fails.

`v=DMARC1; p=reject; pct=100; fo=1; rua=mailto:dmarc-reports@stripe.com; ruf=mailto:dmarc-forensics@stripe.com`

Here's another example to understand the different tags.

v=DMARC1;p=quarantine;pct=100;rua=mailto:report@dmarc.amazon.com;ruf=mailto:report@dmarc.amazon.com

Unlike Stripe, Amazon instructs servers to quarantine emails and send them to spam. This applies to 100% of emails. They also have both a rua address and a ruf address.

How to read DMARC reports

Securing emails with DMARC is only half the battle. The other half is analyzing the data in the reports you get back.

Raw DMARC reports contain report metadata and at least one record. Unfortunately, they're also in XML format. I'm really sorry. I didn't come up with it.

Here's an example aggregate report:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
	<report_metadata>
		<org_name>solarmora.com</org_name>
		<email>noreply-dmarc-support@solarmora.com</email>
		<report_id>9391651994964116463</report_id>
		<date_range>
			<begin>1335571200</begin>
			<end>1335657599</end>
		</date_range>
	</report_metadata>
	<policy_published>
		<domain>mydomain.com</domain>
		<adkim>r</adkim>
		<aspf>r</aspf>
		<p>none</p>
		<sp>none</sp>
		<pct>100</pct>
	</policy_published>
	<record>
		<row>
			<source_ip>203.0.113.209</source_ip>
			<count>2</count>
			<policy_evaluated>
			<disposition>none</disposition>
			<dkim>fail</dkim>
			<spf>pass</spf>
			</policy_evaluated>
		</row>
		<identifiers>
			<header_from>mydomain.com</header_from>
		</identifiers>
		<auth_results>
			<dkim>
				<domain>mydomain.com</domain>
				<result>fail</result>
				<human_result></human_result>
			</dkim>
			<spf>
				<domain>mydomain.com</domain>
				<result>pass</result>
			</spf>
		</auth_results>
	</record>
</feedback>

Let's break this down.

<report_metadata>
	<org_name>solarmora.com</org_name>
	<email>noreply-dmarc-support@solarmora.com</email>
	<report_id>9391651994964116463</report_id>
	<date_range>
		<begin>1335571200</begin>
		<end>1335657599</end>
	</date_range>
</report_metadata>

This is the metadata of the report. The <org_name> contains the name of the ISP that received the email and is sending the DMARC report. The date ranges are in Unix time — use this converter to see the "human" date.

<policy_published>
	<domain>mydomain.com</domain>
	<adkim>r</adkim>
	<aspf>r</aspf>
	<p>quarantine</p>
	<sp>none</sp>
	<pct>100</pct>
</policy_published>

This is the DMARC policy your domain is using at the time of the report. If you've recently changed your DMARC policy, this is useful for filtering reports.

<record>
	<row>
		<source_ip>203.0.113.209</source_ip>
		<count>2</count>
		<policy_evaluated>
		<disposition>none</disposition>
		<dkim>fail</dkim>
		<spf>pass</spf>
		</policy_evaluated>
	</row>
	<identifiers>
		<header_from>mydomain.com</header_from>
	</identifiers>
	<auth_results>
		<dkim>
			<domain>mydomain.com</domain>
			<result>fail</result>
			<human_result></human_result>
		</dkim>
		<spf>
			<domain>mydomain.com</domain>
			<result>pass</result>
		</spf>
	</auth_results>
</record>

Now here's the fun bit: the <record> and its <auth_results>. This record shows the results for 2 emails received from 'mydomain.com'. DKIM has failed, but SPF is passing and the SPF domain is aligned with the <header_from> domain (the sending-domain) so DMARC is passing.

If you send more than a few emails, you'll probably want an easier way to see your DMARC results than in raw XML. You can import it into Microsoft Excel, or use a tool like SendForensics to process it for you.

Key takeaways

• DMARC needs either SPF or DKIM to work, but you should use both for better email security, redundancy and, ultimately, deliverability.
• There are two types of DMARC reports: aggregate (rua) containing all sending data, and forensic (ruf) representing individual emails. ISPs are more reluctant to send ruf reports in this new era of GDPR, CCPA et al, given the PII (personally identifiable information) they can contain. However, most support aggregate reports.
• DMARC aggregate reports are in XML format. You'll need to convert them to a readable format.

Singapore, 3rd September 2020 - SendForensics integrates Google Postmaster Tools data into its Email Deliverability Suite via the long-awaited (and much appreciated) Postmaster Tools API Beta.

As the world's most popular email domain, Gmail forms the bulk of most B2C contact lists, and with the rising popularity of own-domain GSuite implementations, increasingly B2B lists too.

Now legitimate senders can ensure they maintain a good reputational relationship with Google and reach their audiences at Gmail/Gsuite addresses effectively, with Google Postmaster data processed, analysed and displayed directly within the SendForensics platform.

As part of the new Reputation Dashboard, senders’ domain/IP reputation, delivery errors, complaint rates and other Postmaster data is combined with additional reputational feeds, ESP engagement data, and standalone email analysis data, to render the complete deliverability picture.

For more information, visit https://www.sendforensics.com/email-deliverability-overview

About SendForensics:

Founded and headquartered in Singapore, SendForensics is a global provider of advanced email security, deliverability & compliance solutions. Reduce risk, restore trust, and safeguard your brand with SendForensics. Trusted by responsible senders worldwide.

Please note: SendForensics is an independent deliverability company and the ability to connect to and process this API in no way implies an endorsement of SendForensics by Google. This connection is provided for the convenience of our users under the terms and conditions of their respective Postmaster Tools agreements. All product names, trademarks and registered trademarks are the property of their respective owners.

When you send an email from your device using an email client (e.g. Outlook, Apple Mail, Thunderbird etc.) and a standard POP3/IMAP mailbox, the email’s journey will look something like this:

When it’s received by the recipient’s mailserver (M2), the details of both the hop from A —> M1, and the hop from M1 —> M2 will be present in the header of the email ..and this will be scrutinised by M2’s spam-filtering system.

Let’s take a look at what those “Received: from” headers might look like, sending from a laptop in a typical office environment to a Gmail address. Note that when reading an email's headers (view headers/source in most mail programs), the route is in reverse i.e. the first hop is the first “Received: from” line, reading from the bottom-up.

A -> M1

Received: from [10.0.1.5] (mainoffice.companydomain.com [214.85.314.321]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailserver.companydomain.com (Postfix) with ESMTPSA id 3D46C41B1E for <recipient@gmail.com>; Wed, 12 Sep 2018 08:59:20 +0000 (UTC)

This laptop has been assigned the IP address 10.0.1.5 by the office internal network, and the email is being sent through the office's internet-facing dedicated IP 214.85.314.321 (provided by its ISP), which has been set to have the hostname mainoffice.companydomain.com. This hostname when looked-up resolves back to the IP 214.85.314.321, so everything checks out and there's no IP blacklisting (hopefully!).

M1 -> M2

Received: from mailserver.companydomain.com (mailserver.companydomain.com. [132.426.34.45]) by mx.google.com with ESMTPS id s20-v6si492286pgk.87.2018.09.12.01.59.23 for <recipient@gmail.com> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 01:59:23 -0700 (PDT)

It is received by the company mailserver which then delivers it to the Gmail receiving mailserver - all good here.

Now, what might happen to the first hop when you’re out and about:

A -> M1

Received: from [10.124.184.56] (amx-tls3.starhub.net.sg [203.116.164.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailserver.companydomain.com (Postfix) with ESMTPSA id 174CD415EA for <recipient@gmail.com>; Fri, 7 Sep 2018 05:39:38 +0000 (UTC)

Here, my mobile phone has been given the IP address 10.124.184.56 by the telco's 4G network, but the important one here is the telco's server amx-tls3.starhub.net.sg with IP 203.116.164.13. This is in pretty good shape since a lookup on the hostname amx-tls3.starhub.net.sg points to 203.116.164.13, and a reverse DNS lookup on the IP points to the hostname. Therefore forward-confirmed reverse DNS (FCrDNS) checks out; this is a weak but useful form of authentication which receiving mailservers use to help determine whether a sender is legitimate or not. However, the public IP 203.116.164.13 was on two major blacklists at the time of send, marring the receiving server's assessment of the legitimacy of the sender - not good.

It can get worse though...

A -> M1

Received: from [10.124.117.97] (unknown [134.215.314.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailserver.companydomain.com (Postfix) with ESMTPSA id 204DB144BA for <recipient@gmail.com>; Fri, 04 Sep 2018 05:39:38 +0000 (UTC)

This is an example of sending over a network with no server hostname at all, let alone a fully qualified domain name (FQDN). FCrDNS is therefore broken, the receiving server sees an unknown sender in the chain, AND the IP is on several blacklists.

This last example is actually what is often seen when sending through a regular shared-IP VPN, since anonymity can be one of the goals of VPN usage for some. Unfortunately, the anonymity provided can encourage more dodgy uses of VPNs, leading to IP blacklisting for the shared IPs.

How to achieve a reputable sending infrastructure remotely

Two things are needed:

• Control over the reputation of your IP
• A resolvable hostname and corresponding PTR record for the IP so that FCrDNS checks out

This is achievable by using a VPN with a dedicated IP, that also allows setting a PTR record for that IP.

Step 1: Get a compatible VPN

It needs to be able to support the following:

• dedicated IP
• custom PTR record for that IP
• port 465 or 587 open (for secure SMTP)*

*preferably port 587, since 465 has officially been deprecated (although still largely supported)

Step 2: Set up an A record

Within your company DNS, set up an A record for an unused company subdomain that points to your new VPN dedicated IP.

For example:

subdomain.companydomain.com   3600   IN   A   213.312.21.52

Step 3: Set up a PTR record

Request a PTR record be setup for that IP from the VPN provider that resolves to the subdomain above. The request would look something like:

"Please could you add a PTR record for our dedicated IP (213.312.21.52) that points to subdomain.companydomain.com".

That's it!

Once all of this is in place and resolving correctly, you should now see something like this in the first hop when you send:

A -> M1

Received: from [213.312.21.52] (subdomain.companydomain.com [213.312.21.52]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailserver.companydomain.com (Postfix) with ESMTPSA id 1B8D112C78 for <recipient@gmail.com>; Fri, 17 Aug 2018 04:53:06 +0000 (UTC)

The VPN hostname is now the custom subdomain.companydomain.com (created as an A record in the company DNS) which points to the VPN's dedicated IP (213.312.21.52). The IP also resolves back to subdomain.companydomain.com when looked up, so FCrDNS checks out. And since it is not shared with anyone else, the IP can be kept blacklist-free.

You now have a squeaky-clean, secure setup for sending high-quality email on the move.

We're very honoured to be featured in IEEE Software Impact Series as their "first column from the tiger economy of Singapore". In it we discuss the issues facing email in 2017, and how they can be resolved by a new approach to legitimate sending.

There's also a detailed technical breakdown of the software and distributed platforms used to achieve it (if you're into it!).

We're able to make our article available by PDF download (link below), but please note that the copyright belongs to IEEE Software so it may not be re-distributed without express permission.

Download the PDF: IEEE: Delivering Genuine Emails in an Ocean of Spam

On that note, if you are involved in the nuts and bolts of software in any capacity we would highly recommend subscribing to what is one of the world's leading journals for software engineering.

The DMARC email protocol has been available for several years now. Yet while a powerful tool in email authentication, its voluntary take-up, misunderstood benefits, and the myth of complexity that surrounds it has held it back. 2017, however, is shaping up to be its year.

Just 3 years ago, the number of emails sent with DMARC implemented was a small proportion of global email traffic (fig.1). Part of the reason is that it required both sender and receiver to comply with what was an emergent and voluntary protocol.

However, 2016 started to see the larger global freemail providers jump on the bandwagon after seeing what it can do to combat the rise of sophisticated spoofed phishing attacks. Now in 2017, we're experiencing the knock-on effects in the private sector with organisations taking a more pro-active role in protecting their customers, employees and brand; not to mention the added deliverability improvements for marketing and transactional channels.

It's not as difficult as one might think to get compliant, and the benefits are huge.

Now is the time.

What is DMARC?

Very simply, it’s another email authentication protocol. However, DMARC’s been specifically designed to combat the increasing sophistication and proliferation of email scams/phishing-attacks where an email looks like it has come from a legitimate source, but in fact hasn’t.

Technically-speaking, it is a way for a sender to instruct a receiving server on what action it should take if it cannot validate the sender’s From address using either of the other email authentication protocols (SPF/DKIM), for any message sent to it.

The sender’s ‘instructions’ are present in the sender’s DNS records, which the receiver can look up at any time for any message from, or looking like it is from, the sender.

So, to re-phrase, DMARC is a way to authenticate the often-spoofed From address.

Why is it necessary?

Spam and Phishing attacks commonly ‘spoof’ the From address of legitimate companies to fool the user. They will change the From address to something recognisable, which is easily done (whereas the actual email could be coming from anywhere).

Legitimate or not? The From address - easily changed by the sender.

SPF and DKIM protocols are already there to combat this by helping to prove the legitimacy of the sender, but what happens if they do not check out (or are not even enabled)? How does the receiving server know whether the sender has simply not set things up properly, or if it is indeed an intentionally spoofed phishing attack from someone else?

The DMARC records in the sender’s DNS are there to help the receiving server to decide what the reality is.

How does it work?

When a message is received by a receiving server, it will check whether SPF and DKIM authentications pass or fail, and for which domains (From address, Envelope address etc).

If DMARC is enabled on the receiving server, it will also look up the DNS records of the from address to see if there is a DMARC policy.

This policy will contain information as to what it should do if neither of those initial SPF and DKIM authentication checks pass for the From address. They may check out for the other addresses in the email, but there needs to be an SPF or DKIM pass for the From address in order to pass DMARC.

So, if a sender is confident that they have setup SPF and/or DKIM correctly, they might set the policy to say (in layman’s terms):

“If neither SPF and DKIM check-out for our From address, then it’s not an email from us. We suggest you quarantine it for further checks of its legitimacy (or even outright discard it).”

An actual DMARC DNS record that does this would look something like this (for the imaginary acmecompany.com domain):

_dmarc.acmecompany.com 60 TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@acmecompany.com;"

With the following explanations:

_dmarc.acmecompany.com
Host i.e. the name of the DMARC record and which domain it applies to

60
TTL or Time To Live (how quickly the DNS record updates upon change)

TXT
The type of DNS record. DMARC uses TXT

v=DMARC1
The DMARC version being used - this is mandatory and has to come first

p=quarantine
The DMARC policy for what a receiving-server should do with a failed email (here, it suggests quarantine) - this is also mandatory and has to come after the version

rua=mailto:dmarc@acmecompany.com
The address that DMARC reports should be sent to (more about these below) - this is optional

There are, of course, many other options and fine-tuning that can be done when you start getting into it; this is simply an overview to illustrate the basics.

Is it perfect?

No, but close. There are two instances where it can be either ineffectual or problematic:

Ineffectual - if a hijacked computer is used to send phishing email (as part of a botnet, for example) it will pass both SPF and DKIM scrutiny, and also DMARC.

Problematic - very occasionally DNS records can be temporarily inaccessible, or there can be a delay in the information returned which can cause a temporary SPF or DKIM error. If the DMARC policy is set to instruct the receiving server to reject on failure (a very strict policy), there is a chance it can reject legitimate email on a temporary SPF or DKIM error. This issue is minimised since DMARC will pass if either SPF or DKIM passes for the From address domain, but there is still the chance of accidental error (which is why we would not recommend the strictest DMARC policy setting).

The benefits, however, far-outstrip these minor issues.

DMARC Benefits

Security

The most compelling benefit for both senders and receivers is DMARC's ultimate aim: the reduction of successfully-delivered spoofed email.

For the sender this involves ensuring solid SPF and DKIM implementation and a decent policy in the DMARC DNS record, such as recommending quaratine for any emails failing DMARC checks (although many receiving servers will treat emails that fail their own DMARC policy with suspicion anyway).

Another considerable security benefit (with Deliverability overlap, as we will see later) is DMARC's other main feature, which is the reporting of a sender's DMARC activity across the receiver's network.

This takes the form of aggregate (or individual) reports that the sender can request to be sent to it at regular intervals by the receiver. At time of writing, most of the major freemail providers (Google, Outlook et al.) are now set up to produce and send DMARC reports. These contain all the instances of DMARC passes and failures for emails sent to their network from (or purportedly from) the sender, with some extra identifying details (counts, IP addresses, SPF and DKIM authentication results etc).

This feedback can provide valuable insight about a sender's management of internal operations and the presence of external domain name abuse.

Deliverability

As with anything that helps prove the legitimacy of an email, there are email deliverability benefits to be had.

A few years ago these effects were negligible, as the number of receiving servers set up to handle DMARC was a tiny percentage of the overall. However, as can be seen in figure 1. at the top of the article, this is rapidly changing.

Even with a relaxed DMARC policy, the mere fact that there is one in place that checks out, immediately separates your email out from the hordes of spam. This is especially true for the more commonly-spoofed transactional emails delivering official/business/financial content, or requests for information.

Running analytics on DMARC report data can also provide the marketer with additional insights into deliverability patterns or unexpected events. For example, a campaign may suddenly experience a significant drop in engagement with a particular provider, with none of the usual causes (high bounce-rate and other list-problems, poor content quality, blacklisting etc).

It turns out that a rogue IP has been sending thousands of spoofed emails to that provider using your domain as the From address.

How would you know if it wasn't for DMARC?

Successful Implementation

Enabling DMARC is one of the pro-active steps organisations can take in the protection of their customers, employees and the brand itself. It is also one more tick in the box for successful inbox-placement.

These days, most senders will already have SPF and DKIM setup correctly (especially if using the services of an ESP). It's not much of a jump to go from this to the additional benefits of a DMARC ‘pass’ from a receiving server, involving the addition of a valid DMARC record with a bare-minimum implementation. This alone doesn’t take advantage of any of DMARC’s reporting capabilities, but will nevertheless demonstrate compliance.

The next step is setting-up a policy for instructing receiving servers on what to do with email that isn't coming from you, to help prevent spoofed emails from reaching your customers (and employees). Simple enough, but organisational sub-domains and how DMARC should be treated in each case are an added complexity to be considered here, though the protocol adequately allows for specific rules on sub-domains where necessary.

To really reap the benefits, DMARC reports needs to be requested, received and processed, with investigative analytics run on the resulting datasets to identify domain abuse, organisational mis-configurations, and deliverability issues.

The old adage "an elephant never forgets" contains more of an element of truth to it than you might expect. Never is a strong word, but scientists have nevertheless discovered an incredible capacity for memory in these marvellous pachyderms. So what's with the ridiculous title?

A few weeks ago a new customer was testing emails and their postal address kept getting flagged in the system's Copywriting analysis as a spammy phrase. Now, it's a requirement of CAN-SPAM regulations that commercial messages must contain a valid physical (postal) address, so why was it being flagged as problematic?

In (understandable) frustration, the client contacted us for answers. Whenever this happens, we dive into the data manually to try and identify any tell-tale patterns or indicators.

I Know What You Did Last Spammer

Sometimes, a bit of background research is needed to solve this kind of puzzle, so after a bit of sleuthing around, one of our support engineers (let's call him Dominic because that's his name) uncovered a surprising history behind the address..

Turns out that a prolific sender of email scams used to inhabit the same business park address in San Diego, California that our client now resides in. Between 2011 and 2012, they flooded the internet with spam, and were named and shamed as a result:

They inhabited a different unit, but the rest of the address is exactly the same as appeared in both the original scam emails, and now in our client's legitimate email.

At the time, filtering-systems would have used this and other patterns to learn to identify these messages as spam, storing the markers in case they came round again.

It seems their memory held.

What to do? Move..?

It may be that the memory will fade in time, or there is enough legitimate use of the address to eventually override the negative impact. But what can be done in the meantime?

Luckily, addresses can generally be written in a few different ways. Re-writing in a different format is usually enough to break the sequence, rendering the pattern unrecognisable.

To relate it to the case of our client and these spammers, I've anonymised the address but it is in a similar format:

112 East Sample Street, #510, San Diego, CA 90210, USA

The identifiable chunks or 'strings' common to both are "112 East Sample Street" and "San Diego, CA 90210, USA", although the hash symbol (#) is also present.

To disrupt the recognition, the strings could be re-written in the following way, making this the full address:

112 E. Sample St, Unit 510, San Diego, California 90210, United States

Same address, different format, spam-markers reduced, higher deliverability ensues.

An Elephant Never Forgets?

Elephants and spam-filters would indeed appear to have similarly impressive memories then. However, 'perfect' is perhaps too strong a word for even a filtering-system's memory as the environment changes so much over time.

Either new information negates historical effect, or there is simply so much to keep up with that old memories may eventually have to be replaced. Either way, we'll continue to watch that data closely.

It seems appropriate then to close with a more accurate expression for the digital age. Something that the many high-profile victims of leaks and/or the Streisand Effect can attest to:

The Internet Never Forgets.

There, FTFY.

Got a business idea? Thought of a name yet? Okay, let’s check the domain name, hopefully it's avail.. taken. Not to worry, let’s do a subtle varia.. taken. Perhaps the alternative spell.. aaaand it’s taken.

Small wonder we have startups calling themselves Yoose, Qeeple, Ubooly and suchlike.

Well, to add to the numerous considerations when choosing a domain name for your business, or simply a sub-domain for your outbound email marketing activities; here’s another one (sorry).

Did you know the name you choose can affect the deliverability of your emails?

Well, it can, and sometimes the effects can be catastrophic.

We worked with a company who were having real trouble getting even basic one-to-one emails to their clients. The analysis revealed an unusual problem, which took even us by surprise. Their standard company email signature contained, as most do, a link to their site. This was the link:

http://www.executive███.com

Innocent enough, but a spam-filtering system scanning through the mail would see this pattern:

http://www.executive███.com

.exe in an email? The horror.

As the file-extension for Windows executables, this is almost universally blocked by spam-filtering systems as one of the most common attack vectors for viruses/malware etc. Yes, it’s not attached as a file, but if a primitive mailscanner reads .exe, it’s not going to take the chance on a potentially nefarious embedded executable.

Luckily, this is easily fixed by changing the link slightly:

http://executive███.com

Voila, no .exe pattern, problem solved.

Bad luck and subdomains

In a constantly fluctuating environment, the words and phrases ignored by spam-filtering systems one minute can be frowned-upon the next. Simple bad luck can have your chosen domain/sub-domain flagged as a spam-heavy word, but some prior thought can minimise the risks.

We wouldn’t, for example, choose viagra.example.com as a sending subdomain. However, on the other end of the Captain Obvious scale, we’d also stay clear of something like offers.example.com or deals@mailer.example.com if we're talking full sending addresses.

Even purely on string-searching, this kind of behaviour makes it easy for spam-filtering technologies to sort your mail into the 'appropriate' folder (read: spam folder).

As long as it comes from the right domain, very few people notice or care about the full sending address, so you really do have a lot of options for choosing something innocuous to spam-filters.

Choose wisely and, I don't know, perhaps test your choices before you send with some kind of pre-emptive email deliverability system.

You have probably noticed that bulk mail senders often include instructions to add their message to your Safe Senders List in order to bypass future checks. Is this a good idea? Well no, unfortunately.

First of all, for a mail sender to do this, they obviously do not trust their own ability to craft an email so that it will be clearly differentiated as non-spam by most if not all mail servers.

Second, it has a number of problems. For example, if a spammer masquerades with this sending address, (and there is nothing to stop them in the emailing protocol because such spoofing is allowed), the resulting spam will just sail through all your checks, depositing its toxic contents in your inbox. This led Microsoft to remove the possibility of adding a whole domain to the Safe Senders List in Exchange 2010, restricting it to individual addresses only.

Even if a spammer does not spoof the address, you are basically saying to the mail sender that you will trust everything they send in future. No mail sender can guarantee the sanctity of all future email and it is all too common that a toxic link gets unwittingly included in an otherwise genuine bulk mail from a genuine sender.

SendForensics never uses Safe Sender techniques. Instead, every email is subjected to full forensic analysis to mirror the current state of the rapidly changing internet threat landscape. That way deliverability remains a controllable objective measurement rather than an uncontrollable leap of faith.