SPF to allow all servers in domain to send email

Posted on 2014-09-29
Last Modified: 2014-11-11
We recently got added an SPF record
  v=spf1 -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 and 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 -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 -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 -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, even though the "own domain" chould be default as well. Let's see that happens when DNS refreshes...
Get 15 Days FREE Full-Featured Trial

Benefit from a mission critical IT monitoring with Monitis Premium or get it FREE for your entry level monitoring needs.
-Over 200,000 users
-More than 300,000 websites monitored
-Used in 197 countries
-Recommended by 98% of users


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 -all

did not solve the problem, but changing to
  v=spf1 -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 "" itself is checked?

With 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 [] matches the IP that is associated with your A records.


Author Comment

ID: 40351007
I found a great tool at

  v=spf1 -all

this tool explicitly stated that (apart from outlook servers) only the ip address in the A record for "" 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 -all

Is synonymous with:

v=spf1 a -all

Excerpt from
"v=spf1 a -all"
The current-domain is used.

"v=spf1 -all"
Equivalent if the current-domain is

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

"v=spf1 a/24 -all"
If resolves to, the entire class C of would be searched for the client IP. Similarly for 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 "" mechanism, I understood it such as that ALL of the A-records in the sub domain would be allowed (like, etc)
Instead, it seems more and more obvious that the "a" mechanism ONLY checks for the A record (or records) with the specific name "" (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 which is (which is the www web server, of course) and then an A record for 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: 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

Now, when an email is sent from, 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'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 "" (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 and contains an A record in the DNS, then the SPF rule matches.
Thus, with a DNS with the following A-records:

…then your “a” description for seems to mean that the mailsender ( would match the rule, just because that it exists as an A record in
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 instead means (as I’ve understood it) that mail from any IP address that has an A record for the name “” (thus the @ record in the example above) matches.
To allow, one must use an “a” rule that specifically identifies this particular host, or else declare a subnet like “” 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

Get Actionable Data from Your Monitoring Solution

Your communication platform is only as good as the relevance of the information you send. Ensure your alerts get to the right people every time with actionable responses. Create escalation rules that ensure everyone follows the process and nothing is left to chance.

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
Easy CSR creation in Exchange 2007,2010 and 2013
In this video we show how to create a mailbox database in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Servers >> Data…
Established in 1997, Technology Architects has become one of the most reputable technology solutions companies in the country. TA have been providing businesses with cost effective state-of-the-art solutions and unparalleled service that is designed…

695 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