Creating a Missing SPF Record

Q1) Is the above SPF generated Text correct?

No way to say without real data (domain name).

Q2) Should the SPF include both FQDN and all the range of our Pubic IPs? (or either FQDN or Pubic IP is enough).

All IPs sending mail must be included in your SPF record for highest Delivery/Inboxing.

Q3) Is the CIDR accepted as a format on an SPF record?

Yes.

Q4) Should we use all the Range/IP Block of our Public IPs or only the IP 176.35.29.17 of mail.example.com?

Same as answer for Q2.

Q5) I have seen that some other users mention Internal IPs instead of Public ones. Which is correct?

External.

Internal have no meaning... outside your infrastructure.

Said another way, for public email flow, only use public IPs. For internal mail flow, only your tech team can understand this, as all internal routing is hidden from public view.

Q6) The SPF record should be published only in my Domain Controller or should I also create a Record in my ISP Provider (as I did with the MX Records)?

Only your tech team understands this.

I only use external DNS, as using internal + external DNS makes debugging email delivery problems near impossible.

Refer to Q5 answer for more detail about this...

Q7) Once the record is added can I SPF lookup immediately (by usinig MX Toolbox Tool) or it will take effect after some time?

Depends on your DNS record TTLs settings.

I normally set TTL from 1-10 minutes.

You must wait for the TTL to expire, for new DNS records to propagate everywhere.

Tip: Set your TTL to 1 minute while your getting this working.

Tip: Use MXToolbox + Dmarcian tools to verify settings.

Tip: Setup a DMARC reporting record to receive DMARC reports, to ensure all's well.

-->Value: v=spf1 a mx a:mail.example.com ip4:176.35.29.16/28 ~all
~all Replace this with -all.

Thank you all for your comments.

Dear David, thank you for your detailed answer.

- Re Q6 please clarify if it is ok to add the record only on my DNS Server or if the record should be also added to my ISP provider.
- Adding a wrong entry would cause our emails fail to be sent? Should we use the SPF Record with caution?
- Same applies to an DMARC record or it is just for reporting hence if it is wrong generated we will not have correct reports?

Thank you so much for your support

1) Q6 - Only you can answer this, since you haven't provided your actual domain name.

The answer is you must change DNS where ever DNS is being handled.

For example, take the domain https://davidfavor.com looking at DNS...

imac> whois davidfavor.com | egrep -i server
   Registrar WHOIS Server: whois.godaddy.com
   Name Server: NET10.WPFASTSITES.COM
   Name Server: NET11.WPFASTSITES.COM
   Name Server: NET12.WPFASTSITES.COM

Select allOpen in new window

So the answer to your question if your domain name is davidfavor.com is DNS must be changed with the WPFastSites DNS provider.
 
2) SPF is best set correctly. If you add in incorrect sending IPs you open yourself up to these IPs sending SPAM on your behalf.

This would be rare. Likely you know the correct IPs to list in your SPF block, so will have no problems.

3) DMARC policy setting is more complex. I'll go through this in a separate comment.

To correctly upgrade/implement DMARC Policy=Reject, where "correctly" means you'll have near 100% delivery rather than 0% delivery.

1) Setup your DMARC record to send DMARC reports, using a DNS record similar to this...

_dmarc IN TXT "v=DMARC1; p=none; sp=none; fo=1; adkim=s; aspf=s; pct=100; rf=afrf; ri=300; ruf=mailto:dmarc@yourdomain.com; rua=mailto:dmarc@yourdomain.com;"

Select allOpen in new window

2) Check these DMARC reports every day.

This means you'll require writing a parser to tear apart email into the .zip + .gz DMARC reports, then parsing out details of each DMARC report.

3) Fix all missing SPF IPs, you find in #2.

Note: This may require SPF Realtime Patching, if you use a mainstream CRM or ESP, as 100% of all I've tested are broken.

4) Once your SPF delivery problems go to zero, proceed.

Note: You'll never have 0 SPF breakage, because each time someone forges an email from your domain, this should trigger a correct SPF failure.

What you're looking to fix in #1-#3 are incorrect SPF failures.

5) At this point, you should have SPF working + you'll now check DKIM signing.

You'll go through a similar process as you did with SPF. You'll work with every MTA sending mail on your domain's behalf to fix any DKIM signing breakage.

6) Once all SPF + DKIM problems are fixed, change your DMARC record as follows...

Change "p=none; sp=none;" to "p=reject; sp=reject;" which will instruct Mailbox Providers to block submission of any message with either SPF or DKIM breakage.

7) When you flip the switch in #6, if any minor breakage is occurring for 100% of messages, then 100% of messages will be blocked by almost all Mailbox Providers.

This is why going through this process one step at a time is essential.

If you miss any step, then you can end up with 0% mail delivery.

Also if you use a mainstream CRM/ESP without SPF Patching, then eventually they will make some change that will cause large scale email delivery problems, which is what got me working on fixing this problem set years ago.

Good luck!

Q6) The SPF record should be published only in my Domain Controller or should I also create a Record in my ISP Provider (as I did with the MX Records)?

Just in case there's still some question about this, your SPF record has to be accessible from recipients' mail servers to be of any use, since they're the ones that will be performing SPF checks against your domain when they receive messages from you. Unless you're running your own public DNS server, this record needs to be created using your domain registrar's DNS control panel.

Tip: If you provide your actual domain name, EE'ers can test + let you know if any problems stand out.

Dear David,

Thank you so much for all the info provided although I struggle to understand each line of your last post since I have limited knowledge on DNS matters.

According to your last post, if my understanding is correct:

1) You Create the SPF Record
2) You enable the DMARC with "unrestricted" settings in order to monitor mail flow
3) Once the SPF Failures become zero you create DKIM signing
4) Once SPF + DKIM have zero failures you tighten the settings of DMARC

Is the above correct?

Moreover, after doing a Whois Lookup I confirmed that I need to contact my ISM provider who is also my DNS provider to create for me the SPF record.

The syntax of SPF seems straight forward. I will inform my ISP/DNS provider to create a record of the FQDN of my mail server accompanied with all the IP Range of my Static IPs.

So the syntax will look like this: Value: v=spf1 a mx a:mail.example.com ip4:First_IP/CIDR -all

Assuming that I do not wish to enable DKIM signing at this point, why do I need DMARC to fix all missing IPs (as per your last post of step #3)?

I mean, why should I have missing IPs? I have 1 Site, with 1 Mail Server and an IP Block of 16 IPs.


If I include them all into the SPF Record and provided that the creation of DKIM will be postponed for a later stage, why should I need DMARC logging?

Could you please anyone assist me on my last post?

My main questions are:

- If I create only an SPF Record including all my Public IP Sub net will be enough?
- Since I will include all the available IPs am I exposed to delivery failures due to SPF?
- DMARC and DKIM is a "must" or I could skip the creation of them for now?

I look forward to your inputs,
Mamelas

Something for you to consider...

You said, "Thank you so much for all the info provided although I struggle to understand each line of your last post since I have limited knowledge on DNS matters."

You're welcome!

And, best if you provide your actual domain name, so 100% correct guidance can be provided.

Email DNS records are more complex than they might seem, so best to work with real domain/host names, so all settings are correct.

Minor mistakes, can drop email delivery to 0.

So if you do this yourself (without providing your domain/host name involved), you'll require a very steep learning curve to keep your delivery high.

Your sequence is almost correct.

1) Setup OpenDKIM + verify message signing is correct.
2) Setup your SPF record correctly.
3) Setup DMARC record with "unrestricted" settings ("p=none;sp=none") in order to monitor mail flow
4) Once SPF + DKIM have zero failures you tighten the settings of DMARC to "p=reject;sp=reject".

Tip: You can easily check if your SPF + DKIM + DMARC settings are all correct by doing this...

1) Send a message to a Gmail address.
2) Click on message.
3) From drop down (vertical dots) select "Original Message".
4) There will be a clear pass/fail for all 3x SPF + DKIM + DMARC test Gmail has conducted.

Using the "Original Message" is worth it's weight in gold, debugging Delivery/Inboxing problems.

You asked, "If I include them all into the SPF Record and provided that the creation of DKIM will be postponed for a later stage, why should I need DMARC logging?"

Today having a missing DMARC record or "p=none;sp=none" only results in negative reputation for every message sent.

Google + Microsoft have already stated (in dev backchannels) they will soon start blocking all mail where a domain is missing "p=reject;sp=reject".

If you require highest per message reputation, which produces highest Inboxing, the setting "p=reject;sp=reject" is a must.

After Google + Microsoft "flip the switch" requiring DMARC "p=reject;sp=reject", likely all Mailbox Providers will follow their lead, so at this point, you'll require setting DMARC "p=reject;sp=reject" for any Delivery at all.

This isn't anything new.

This has been coming for years.

Best to fix this now, before Delivery goes to 0.

Dear David,

In response to your last posts which were more than welcome:

 - And, best if you provide your actual domain name, so 100% co-rrect guidance can be provided

This is a corporate Domain and I am not "allowed" to post any information.
It would be a lot of help if you could advise the tools you need to test my domain.
I would then revert with results by masking the "sensitive" data or by altering the IPs & FQDNs.


Alternatively it would be also helpful if you could provide me step-by-step documentation/links
for setting up the following on my own:

- Your sequence is almost correct:
   1) Setup OpenDKIM + verify message signing is correct.
   2) Setup your SPF record correctly.
   3) Setup DMARC record

Awaiting yours,
Mamelas

Thank you all for your support!

It seems that I have to request assistance from a Service Provider who has the tools and knowledge to help me correctly configure
SFP, DMARC and DKIM.