Skip to main content
let's get that sample SPF record on just one line without it wrapping
Source Link
Adam Katz
  • 12.6k
  • 2
  • 29
  • 54

I agree that half or more of worldwide email is probably sent through shared infrastructure, including ISPs, freemail providers (Google, Yahoo, and Microsoft), and multi-tenant cloud providers (especially the corporate options from Microsoft and Google).

As the Forward Pass paper proved, SPF does not work with shared infrastructure. It does, however, work fine with dedicated IPs. This can alleviate the need to set up DKIM on a less important (but still secured) server that just sends mail with cron jobs and other operational contexts.

I therefore suggest an SPF record like v=spf1 a:www.example.com ?include:_spf.google.com ~all where www.example.com is a (non-shared!) non-mail server that happens to send some cron jobs but doesn't have DKIM set up. The entry's ?include means its included entries are SPF-neutral (not passing, not failing). Anything you sendsent through Google should be DKIM-signed, so it willshould pass DMARC just fine.fine—but don't forget to verify that before enabling a DMARC p=reject policy!

(Having an empty SPF record, or worse, one that denotes the shared infrastructure you've intentionally omitted should be failed or soft-failed, is harmful to your ability to deliver mail. I do not recommend those paths.)

I agree that half or more of worldwide email is probably sent through shared infrastructure, including ISPs, freemail providers (Google, Yahoo, and Microsoft), and multi-tenant cloud providers (especially the corporate options from Microsoft and Google).

As the Forward Pass paper proved, SPF does not work with shared infrastructure. It does, however, work fine with dedicated IPs. This can alleviate the need to set up DKIM on a less important (but still secured) server that just sends mail with cron jobs and other operational contexts.

I therefore suggest an SPF record like v=spf1 a:www.example.com ?include:_spf.google.com ~all where www.example.com is a (non-shared!) non-mail server that happens to send some cron jobs but doesn't have DKIM set up. The entry's ?include means its included entries are SPF-neutral (not passing, not failing). Anything you send through Google should be DKIM-signed, so it will pass DMARC just fine.

(Having an empty SPF record, or worse, one that denotes the shared infrastructure you've intentionally omitted should be failed or soft-failed, is harmful to your ability to deliver mail. I do not recommend those paths.)

I agree that half or more of worldwide email is probably sent through shared infrastructure, including ISPs, freemail providers (Google, Yahoo, and Microsoft), and multi-tenant cloud providers (especially the corporate options from Microsoft and Google).

As the Forward Pass paper proved, SPF does not work with shared infrastructure. It does, however, work fine with dedicated IPs. This can alleviate the need to set up DKIM on a less important (but still secured) server that just sends mail with cron jobs and other operational contexts.

I suggest an SPF record like v=spf1 a:www.example.com ?include:_spf.google.com ~all where www.example.com is a (non-shared!) non-mail server that happens to send some cron jobs but doesn't have DKIM set up. The entry's ?include means its included entries are SPF-neutral (not passing, not failing). Anything sent through Google should be DKIM-signed, so it should pass DMARC just fine—but don't forget to verify that before enabling a DMARC p=reject policy!

(Having an empty SPF record, or worse, one that denotes the shared infrastructure you've intentionally omitted should be failed or soft-failed, is harmful to your ability to deliver mail. I do not recommend those paths.)

Source Link
Adam Katz
  • 12.6k
  • 2
  • 29
  • 54

I agree that half or more of worldwide email is probably sent through shared infrastructure, including ISPs, freemail providers (Google, Yahoo, and Microsoft), and multi-tenant cloud providers (especially the corporate options from Microsoft and Google).

As the Forward Pass paper proved, SPF does not work with shared infrastructure. It does, however, work fine with dedicated IPs. This can alleviate the need to set up DKIM on a less important (but still secured) server that just sends mail with cron jobs and other operational contexts.

I therefore suggest an SPF record like v=spf1 a:www.example.com ?include:_spf.google.com ~all where www.example.com is a (non-shared!) non-mail server that happens to send some cron jobs but doesn't have DKIM set up. The entry's ?include means its included entries are SPF-neutral (not passing, not failing). Anything you send through Google should be DKIM-signed, so it will pass DMARC just fine.

(Having an empty SPF record, or worse, one that denotes the shared infrastructure you've intentionally omitted should be failed or soft-failed, is harmful to your ability to deliver mail. I do not recommend those paths.)