SPF to allow all servers in domain to send email

Posted on 2014-09-29
Medium Priority
Last Modified: 2014-11-11
We recently got added an SPF record
  v=spf1 include:spf.protection.outlook.com -all

in our DNS, when migrating to office365 - however, the guys forgot that we send email from some additional in-house servers as well. Those emails now get rejected by SPF-aware recipients.

Our domain (let call it company-com) contains A records for our mail-sending servers srv1.company.com and srv2.company.com and we've got PTR records in place to resolve the servers ip addresses back to their names.
And now, of course, we need to fix the SPF record that was added to the DNS

As both srv1 and srv2 are listed with A-records in our domain, I thought that adding a "+a" would fix it:
  v=spf1 +a include:spf.protection.outlook.com -all

However, that doesn't seem to work. If I add "ip4: ip4:" (ip address to srv1 and srv2) it seems to work ok, but I'd rather not bind this to the ip addresses.

Isn't the +a method the correct way to do this?
Question by:stefanlennerbrant
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 10
  • 4
LVL 16

Expert Comment

by:Joshua Grantom
ID: 40350834
just remove the plus(+). You may also want to make sure that your MX rcords are included in the SPF.

v=spf1 a include:spf.protection.outlook.com -all

Here is a good place to look at SPF syntax

LVL 34

Expert Comment

ID: 40350844
Your usage looks fine.  But I might add ptr to it.

v=spf1 a ptr include:spf.protection.outlook.com -all

A            If the domain name has an address record (A or AAAA) that can be resolved to the sender's address, it will match.

More on SPF:


You can also use MxToolBox to validate your SPF records:



Author Comment

ID: 40350846
According to spec, a and +a are identical (the + is default)
I'll try, though.
I just changed to a:company.com, even though the "own domain" chould be default as well. Let's see that happens when DNS refreshes...
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Author Comment

ID: 40350884
I now note that the spec (openspf) says, for the A mechanism, that:
  All the A records for domain are tested. If the client IP is found among them, this mechanism matches.

Does this mean that a zone transfer is performed? And this that the DNS must allow zone transfers for the SPF "a" to be working? I don't find any information on that, though...

Author Comment

ID: 40350903
@it_saige, yes using "ptr" seems to solve the problem.
However, openspf docs states that:
  If at all possible, you should avoid using this mechanism in your SPF record, because it will result in a larger number of expensive DNS lookups.

I had guessed that "a" would be the perfect mechanism to use - but, evidently, it does not work in my situation.
Could it really be a problem with zone transfers? Or what else would make "a" fail?

Author Comment

ID: 40350985
Well changing to
  v=spf1 a:company.com include:spf.protection.outlook.com -all

did not solve the problem, but changing to
  v=spf1 a:srv1.company.com/24 include:spf.protection.outlook.com -all

fixed it.

Maybe I don't understand what "a" does check? From openspf I understood that all A records in the domain (that the mail claims to originate from) are checked and compared with the actual sending MTA.
However, it seems (?) like only the A record for "company.com" itself is checked?

With a:srv1.company.com/24 it works, as it seems like the receiving MTA looks up the A-record for the server srv1 (one of the mailing servers) and then allows all other servers on the same C-net (due to /24) which includes srv2

I cannot find any better documentation on that "a" mechanism really does. Any pointers to more reading?
LVL 34

Expert Comment

ID: 40350991
I cannot imagine that it would be a problem with zone transfers.  One possibility is that you have mismatched IP's between where the mail is being sent from and where it is recieved to.

Check the outbound mail headers to see if the Received: from [xxx.xxx.xxx.xxx] matches the IP that is associated with your A records.


Author Comment

ID: 40351007
I found a great tool at http://emailstuff.org/spf

  v=spf1 a:company.com include:spf.protection.outlook.com -all

this tool explicitly stated that (apart from outlook servers) only the ip address in the A record for "company.com" would be accepted for mail sending. Not any of the other A record ip addresses in the same domain

Thus, I understand that the "a" mechanism does not really take a "domain name" argument, but rather a "server name" argument (unless, of course, a domain name argument is further investigated with a zone transfer for all A records in the domain -- our DNS however does not allow zone transfers)

I really need to catch up on SPF syntax :-)

If someone could let me know if this issue (is it "domain name" or "server name" that is the argument to "a"), then I would be grateful...
LVL 34

Expert Comment

ID: 40351017
Well according to the specification:

v=spf1 a:company.com include:spf.protection.outlook.com -all

Is synonymous with:

v=spf1 a include:spf.protection.outlook.com -all

Excerpt from www.openspf.org/SPF_Record_Syntax
"v=spf1 a -all"
The current-domain is used.

"v=spf1 a:example.com -all"
Equivalent if the current-domain is example.com.

"v=spf1 a:mailers.example.com -all"
Perhaps example.com has chosen to explicitly list all the outbound mailers in a special A record under mailers.example.com.

"v=spf1 a/24 a:offsite.example.com/24 -all"
If example.com resolves to, the entire class C of would be searched for the client IP. Similarly for offsite.example.com. If more than one A record were returned, each one would be expanded to a CIDR subnet.
Which is what leads me to believe that your A record points to one IP but the IP in the mail is comming from a different IP.


Author Comment

ID: 40351083
@it_saige, your last two quotes are quite good. I saw them previously (on the net) while looking for input, but I obvisouly didn't really get it then...

With the "a:mailers.example.com" mechanism, I understood it such as that ALL of the A-records in the sub domain mailers.example.com would be allowed (like srv1.mailers.example.com, etc)
Instead, it seems more and more obvious that the "a" mechanism ONLY checks for the A record (or records) with the specific name "mailers.example.com" (which, to me, then is considered a server name, rather than a domain name)

Normally (right?), a company domain name by itself is used in an A record to complement the "www" server on the domain.
Thus, a simple "a" SPF mechanism will then only mean that the www webserver in the domain is allowed to send email.

Do you agree? If this is correct, I'd say that much info on the internet is a little confused on this matter :-)

The RFC 7208 however states this a little clearer (I'm sorry I didn't begin by checking this):
5.3.  "a"
   This mechanism matches if <ip> is one of the <target-name>'s IP
   addresses.  For clarity, this means the "a" mechanism also matches
   AAAA records.
      a = "a" [ ":" domain-spec ] [ dual-cidr-length ]
   An address lookup is done on the <target-name> using the type of
   lookup (A or AAAA) appropriate for the connection type (IPv4 or
   IPv6).  The <ip> is compared to the returned address(es).  If any
   address matches, the mechanism matches.

This quite clearly states the the "target name" (the name following the "a:" - defaulting to the mail sender domain name) is looked-up in DNS for its A record. No other A records are looked-up.

So - if I've got an A record for company.com which is (which is the www web server, of course) and then an A record for srv1.company.com which is - then my "a" mechanism does not at all allow the srv1 server to send mail.

Much of the info on the net describes the "a" mechanism with something like the following, which seems to be completely wrong. Don't you agree?
In this SPF record, the “a” mechanism defines that all A records in this domain are permitted to send emails for this domain. The “mx” mechanism defines the same for all the MX records. The “-all” mechanism defines that everything else is not permitted. In most cases, that is what you need if you have a mail server that is just running for this domain.

At least myself am led to Believe, by such text, that ALL of the A-records in all of the domain, are allowed by SPF, with the "a" mechanism (just as is the case with the "mx" mechanism, which allows ALL of the MX servers)
However, all seems to indicate that ONLY the ip address (or addresses) in the A record for the domain name itself, is allowed...
LVL 34

Expert Comment

ID: 40351120
I think you may be over complicating this which is leading to a tiny bit of confusion.

SPF works off the premise of reverse-lookup.  An SPF is not resolved until an email is received.  So using your scheme:

example.com DNS Zone file
A Record	Points To

CName Record	Points To
www		@

TXT Record
v=spf1 a -all

Open in new window

@ in this case simply means example.com.

Now, when an email is sent from example.com, the email has the ip address it was sent from in the headers.  When the recipient email server receives the email, it uses the IP in the email to see if it conforms to what is allowed by the SPF record.  In this case, it should not fail if the IP in the headers is either or as they are both A records that are registered in example.com's DNS zone.


Author Comment

ID: 40351136
Nope, sorry - not as I see it, and have tested it.

With the sample zone that you describe above, emails sent from will not be allowed by SPF

The receiving MTA will see the "a" in the SPF record, and will lookup the A-record for the domain "company.com" (being specified as the domain name in the "MAIL FROM" email address)
This lookup will result in ip address

As this does not match the sending - the mail will not be allowed.

However, much info on the net does indicate, more or less, that ALL of the A-records (including in the domain will be checked and allowed by the "a" mechanism. But that is obvisouly not the case.
(and also, such a solution would need a costly and quite commonly disallowed zone transfer)

Accepted Solution

stefanlennerbrant earned 0 total points
ID: 40351141
...well, of course, the part with a zone transfer would not be needed if SPF would make a reverse-lookup on the ip address itself -- but that is what the "ptr" mechanism is for; and that mechanism is either recommended against or more directly specified as "depreceated"

So, in conclusion, the "a" mechanism only seems to check the A record for the domain name itself - it does not in any way allow any other hosts in the same domain (which of course have their own A records)

Author Comment

ID: 40427946
FYI I just talked to some guys at MxToolbox, asking this (rather long:-) question:
You describe the “a” SPF rule as: “Match if IP has a DNS 'A' record in given domain”

This suggests that if a mail sending server is named mailsender.domain.com and contains an A record in the domain.com DNS, then the SPF rule matches.
Thus, with a domain.com DNS with the following A-records:

…then your “a” description for domain.com seems to mean that the mailsender ( would match the rule, just because that it exists as an A record in domain.com
However, this is (as far as I know) not correct. Or am I wrong?
I’ve been working quite a lot on such issues, and to my experience this is not the way the “a” rule works.

The SPF “a” rule for domain.com instead means (as I’ve understood it) that mail from any IP address that has an A record for the name “domain.com” (thus the @ record in the example above) matches.
To allow mailsender.domain.com, one must use an “a” rule that specifically identifies this particular host, or else declare a subnet like “domain.com/24” in the “a” rule, to allow all IP addresses in the same subnet as the address (the A record for @)

To my knowledge, this “misunderstanding” on how SPF “a” works, is quite common on the internet.
As you are such an authority on the matter, perhaps you could either tell me that I’m wrong :-) or else make some clarification in your SuperTool to avoid that people misinterprets the results.

I then got the answer below, clarifying that the "a" rule only mathces the A record for the domain itself, not all A records that exists in the whole domain
We mean that if the Ip is in the domain's A record then it matches. I'll forward this along to our engineering team to clarify the entry. Thanks for taking the time to let us know it's not confusing. Sometimes things make sense to us since we write them and not to anyone else.

Author Closing Comment

ID: 40434592
In particular, the response from the MxToolBox people (authorities on the matter) seems to settle this issue.

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Resolve Outlook connectivity issues after moving mailbox to new Exchange 2016 server
When you’re making plans to join the modern business race, you should analyze various details that may affect your results. Nowadays, millions of businesses are trying to grow into established and appreciated professional enterprises.
Familiarize people with the process of utilizing SQL Server stored procedures from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Micr…
In this video we show how to create a Resource Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: Navigate to the Recipients >> Resources tab.: "Recipients" is our default selection …
Suggested Courses
Course of the Month12 days, 17 hours left to enroll

777 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question