<div>
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.
</div>

Service Manager

mamelas

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

<div>
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
</div>

<div>
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 <a href="https://davidfavor.com" rel="ugc">https://davidfavor.com</a>&nbsp;looking at DNS... 
 

<pre><code class="code-1 nolinks" id="code-20-43062020-1">imac&gt; 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
</code></pre>
 
So the answer to your question if your domain name is davidfavor.com is DNS must be changed with the WPFastSites DNS provider. 
&nbsp; 
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.
</div>

<div>
To correctly upgrade/implement DMARC Policy=Reject, where &quot;correctly&quot; 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... 
 

<pre><code class="code-1 nolinks" id="code-20-43062036-1">_dmarc IN TXT &quot;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;&quot;
</code></pre>
 
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 &quot;p=none; sp=none;&quot; to &quot;p=reject; sp=reject;&quot; 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!
</div>

<div>
<blockquote>
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)?
</blockquote>
 
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.
</div>

Fractional CTO

David Favor

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

<div>
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 &quot;unrestricted&quot; 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?
</div>

<div>
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 &quot;must&quot; or I could skip the creation of them for now? 
 
I look forward to your inputs, 
Mamelas
</div>

<div>
Something for you to consider... 
 
You said, &quot;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.&quot; 
 
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.
</div>

<div>
Your sequence is almost correct. 
 
1) Setup OpenDKIM + verify message signing is correct. 
2) Setup your SPF record correctly. 
3) Setup DMARC record with &quot;unrestricted&quot; settings (&quot;p=none;sp=none&quot;) in order to monitor mail flow 
4) Once SPF + DKIM have zero failures you tighten the settings of DMARC to &quot;p=reject;sp=reject&quot;. 
 
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 &quot;Original Message&quot;. 
4) There will be a clear pass/fail for all 3x SPF + DKIM + DMARC test Gmail has conducted. 
 
Using the &quot;Original Message&quot; is worth it's weight in gold, debugging Delivery/Inboxing problems.
</div>

<div>
You asked, &quot;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?&quot; 
 
Today having a missing DMARC record or &quot;p=none;sp=none&quot; 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 &quot;p=reject;sp=reject&quot;. 
 
If you require highest per message reputation, which produces highest Inboxing, the setting &quot;p=reject;sp=reject&quot; is a must. 
 
After Google + Microsoft &quot;flip the switch&quot; requiring DMARC &quot;p=reject;sp=reject&quot;, likely all Mailbox Providers will follow their lead, so at this point, you'll require setting DMARC &quot;p=reject;sp=reject&quot; 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.
</div>

<div>
Dear David, 
 
In response to your last posts which were more than welcome: 
 
&nbsp;- 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 &quot;allowed&quot; 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 &quot;sensitive&quot; data or by altering the IPs &amp;&nbsp;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: 
&nbsp; &nbsp;1) Setup OpenDKIM + verify message signing is correct. 
&nbsp; &nbsp;2) Setup your SPF record correctly. 
&nbsp; &nbsp;3) Setup DMARC record 
 
Awaiting yours, 
Mamelas
</div>

<div>
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.
</div>

<div>
<div class="content wysiwyg-content">
Dear Experts, 
 
Some of our outgoing emails are marked as Spam to the Receiver's Mail Servers since we do not have an SPF Record. 
 
Our Environment: 
1 Forest 
1 Domain 
2 Windows 2012 Domain Controllers (one primary, one backup) 
1 On-Premise Exchange Server 2013 
1 Cisco Anti-Spam Server which is our email gateway 
 
For the purposes of this question please find an example of domain, mx records and IPs: 
 
Domain: example.com 
Anti-Spam Server: mail.example.com 
Public IP of Anti-Spam Server: 176.35.29.17 
Internal IP of Anti-Spam Server: 10.1.1.51 
Internal IP of Exchange Server: 10.1.1.43 
Public IP Range: 176.35.29.16 (first IP), 176.35.29.31 (last IP) 
 
I have created an SPF record by using the relevant wizard/tool of <a href="https://mxtoolbox.com/SPFRecordGenerator.aspx" rel="ugc">MXToolbox - SPF Record Generator</a> 
 
 

<blockquote>
 
Type: TXT 
Host/Name: example.com 
Value: v=spf1 a mx a:mail.example.com ip4:176.35.29.16/28 ~all 

</blockquote>
 
 
According to the message headers provided from the recipient in which our email was blocked, the mail.example.com with IP 176.35.29.17 has no SPF record. 
 
Q1) Is the above SPF generated Text correct? 
Q2) Should the SPF include both FQDN and all the range of our Pubic IPs? (or either FQDN or Pubic IP is enough) 
Q3) Is the CIDR accepted as a format on an SPF record? 
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? 
Q5) I have seen that some other users mention Internal IPs instead of Public ones. Which is correct? 
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)? 
Q7) Once the record is added can I SPF lookup immediately (by usinig MX Toolbox Tool) or it will take effect after some time? 
 
To help me out, you are kindly requested to use the numbering for each question you are answering to. 
 
Thanks in advance, 
Mamelas
</div>
</div>

Dear Experts,

Some of our outgoing emails are marked as Spam to the Receiver's Mail Servers since we do not have an SPF Record.

Our Environment:
1 Forest
1 Domain 
2 Windows 2012 Domain Controllers (one primary, one backup)
1 On-Premise Exchange Server 2013
1 Cisco Anti-Spam Server which is our email gateway

For the purposes of this question please find an example of domain, mx records and IPs:

Domain: example.com
Anti-Spam Server: mail.example.com
Public IP of Anti-Spam Server: 176.35.29.17
Internal IP of Anti-Spam Server: 10.1.1.51
Internal IP of Exchange Server: 10.1.1.43 
Public IP Range: 176.35.29.16 (first IP), 176.35.29.31 (last IP)

I have created an SPF record by using the relevant wizard/tool of MXToolbox - SPF Record Generator (https://mxtoolbox.com/SPFRecordGenerator.aspx)



Type: TXT
Host/Name: example.com
Value: v=spf1 a mx a:mail.example.com ip4:176.35.29.16/28 ~all



According to the message headers provided from the recipient in which our email was blocked, the mail.example.com with IP 176.35.29.17 has no SPF record.

Q1) Is the above SPF generated Text correct?
Q2) Should the SPF include both FQDN and all the range of our Pubic IPs? (or either FQDN or Pubic IP is enough) 
Q3) Is the CIDR accepted as a format on an SPF record?
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?
Q5) I have seen that some other users mention Internal IPs instead of Public ones. Which is correct?
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)?
Q7) Once the record is added can I SPF lookup immediately (by usinig MX Toolbox Tool) or it will take effect after some time?

To help me out, you are kindly requested to use the numbering for each question you are answering to.

Thanks in advance,
Mamelas

Creating a Missing SPF Record

Exchange is the server side of a collaborative application product that is part of the Microsoft Server infrastructure. Exchange's major features include email, calendaring, contacts and tasks, support for mobile and web-based access to information, and support for data storage.

Exchange

Windows Server 2012 is the server version of Windows 8 and the successor to Windows Server 2008 R2. Windows Server 2012 is the first version of Windows Server to have no support for Itanium-based computers since Windows NT 4.0. Windows Server 2012, now in its second release (Windows Server 2012 Release 2) includes Foundation, Essentials, Standard and Datacenter, and does not support IA-32 or IA-64 processors.

Windows Server 2012

SPF Records

Within Internet message handling services (MHS), a message transfer agent or mail transfer agent (MTA) or mail relay is software that transfers electronic mail messages from one computer to another using a client–server application architecture. A MTA implements both the client (sending) and server (receiving) portions of the Simple Mail Transfer Protocol (SMTP). The terms mail server, mail exchanger, and MX host may also refer to a computer performing the MTA function. The Domain Name System (DNS) associates a mail server to a domain with mail exchanger (MX) resource records containing the domain name of a host providing MTA services.