asked on Adding SPF records to DNS and Exchange 2010
We have delivery failures for an external domain, not passing SPF checks. Do we just add a SPF entry for this mail server under our domain and correct this problem? i.e. outside domain SPF.....domain.it . IN TXT "vspf1 mx a a:smtp.domain.it Do we need an IP?
Do we need to do anything to Exchange 2010?
Thanks
Do we need to do anything to Exchange 2010?
Thanks
DNSExchange
Last Comment
Harold
There would be no point having SPF records if anybody could create them for any domIn they wanted. Only the domain owner can add spf records on their own dns records.
ASKER
Maybe I didn't explain where I'm confused. This is the email we received. We've setup our SPF records, and I know they should do the same, why not, don't know. I'm looking for what other changes we're to make, beyond what we've done, based on below.
Some organisations email servers are using the SPF protocol. This means that when the mail server receives an email, before delivering it to the inbox, checks if the SMTP server from which they received it, matches the record in the SPF registry for the sender's domain. Such a record exists only if the sender is also using the SPF protocol. Those stmp server records are added to the SPF registry by the domain owner and signify that they are authorized to send email on behalf of the owner's domain. In our case, when, for example, Micro2gen sends an email to the inachus mailing list inachus-all@iccs.gr, this email is forwarded from the iccs SMTP server to the NTUA SMTP server and finally to the members of the list. The email's sender is XXXX@micro2gen.com and the forwarding SMTP server smtp.ntua.gr. When EXUS mail server receives that email, rejects it, because there is no smtp.ntua.gr record in the SPF registry for the micro2gen.com domain. Therefore, Micro2gen and EXUS cannot receive each other's email sent to the list. They receive, of course, the rest of the partners' emails, who do not use SPF. Our suggestion is that all the organisations in INACHUS add, as long as the project lasts, records of the NTUA SMTP servers to the SPF registry, for their domains.
Some organisations email servers are using the SPF protocol. This means that when the mail server receives an email, before delivering it to the inbox, checks if the SMTP server from which they received it, matches the record in the SPF registry for the sender's domain. Such a record exists only if the sender is also using the SPF protocol. Those stmp server records are added to the SPF registry by the domain owner and signify that they are authorized to send email on behalf of the owner's domain. In our case, when, for example, Micro2gen sends an email to the inachus mailing list inachus-all@iccs.gr, this email is forwarded from the iccs SMTP server to the NTUA SMTP server and finally to the members of the list. The email's sender is XXXX@micro2gen.com and the forwarding SMTP server smtp.ntua.gr. When EXUS mail server receives that email, rejects it, because there is no smtp.ntua.gr record in the SPF registry for the micro2gen.com domain. Therefore, Micro2gen and EXUS cannot receive each other's email sent to the list. They receive, of course, the rest of the partners' emails, who do not use SPF. Our suggestion is that all the organisations in INACHUS add, as long as the project lasts, records of the NTUA SMTP servers to the SPF registry, for their domains.
The entries "a" and "a:smtp.domain.it" are redundant, IF the domain/zone file you are adding this to is also for domain.it.
If the SPF entry is not in the dns record for "domain.it", and "smtp.domain.it" is another domain entirely you are trying to "auth", then use "include:smtp.domain.it".
You are on the right track. "MX" entry means "for this domain, any mx server named in the zone is considered authed to send smtp mail". A, same thing for any A record of the domain (hence why a:smtp.domain.it is redundant...IF the domain in question is "domain.it".
You can just name the ip of your smtp servers you are trying to auth with "ip4:x.x.x.x". If you are using ipv6, then use "ip6:ipv6addresshere"
Here's a good one to start with:
"v=spf1 a mx ip4:x.x.x.x ip4:y.y.y.y nclude:any.otherdomain.com
You can add multiple ip4: and include: statements (as well as ip6:). The ~all is a "soft fail" or any other ip / host not specifically permitted. I'd use that until you are sure your SPF is doing it's job.
If the SPF entry is not in the dns record for "domain.it", and "smtp.domain.it" is another domain entirely you are trying to "auth", then use "include:smtp.domain.it".
You are on the right track. "MX" entry means "for this domain, any mx server named in the zone is considered authed to send smtp mail". A, same thing for any A record of the domain (hence why a:smtp.domain.it is redundant...IF the domain in question is "domain.it".
You can just name the ip of your smtp servers you are trying to auth with "ip4:x.x.x.x". If you are using ipv6, then use "ip6:ipv6addresshere"
Here's a good one to start with:
"v=spf1 a mx ip4:x.x.x.x ip4:y.y.y.y nclude:any.otherdomain.com
You can add multiple ip4: and include: statements (as well as ip6:). The ~all is a "soft fail" or any other ip / host not specifically permitted. I'd use that until you are sure your SPF is doing it's job.
Yeah, you are running into a limitation of SPF.
SPF records indicate, to a receiving email server, which IP addresses should be sending email from this domain. In this case, email from your domain is being redirected by another server. Thus, the SPF records do not match; it is sending email fro an IP not included in your SPF record.
You could possibly edit the SPF records to include the redirecting server.
Here re a couple of helpful links:
http://www.openspf.org/Best_Practices/Forwarding
https://productforums.google.com/forum/#!topic/gmail/os_pye9rUlM
https://forums.cpanel.net/threads/spf-and-forwarding-mail-to-a-gmail-account.86141/
SPF records indicate, to a receiving email server, which IP addresses should be sending email from this domain. In this case, email from your domain is being redirected by another server. Thus, the SPF records do not match; it is sending email fro an IP not included in your SPF record.
You could possibly edit the SPF records to include the redirecting server.
Here re a couple of helpful links:
http://www.openspf.org/Best_Practices/Forwarding
https://productforums.google.com/forum/#!topic/gmail/os_pye9rUlM
https://forums.cpanel.net/threads/spf-and-forwarding-mail-to-a-gmail-account.86141/
ASKER
Malmensa: so if I'm reading what you posted correctly and what I know of SPF and currently have configured, we really cannot control coming in just going out, correct? So should I put "their" servers IP in our SPF setting or add another SPF record to our domain?
The rules on SPF are easy, if you understand the flow. The SPF entry is for the said domain owner to "publish" which SMTP servers are allowed to SEND mail on the domains behalf. It has nothing to do with the domains incoming mail (mail handed to the same domains incoming SMTP servers).
You are basically saying "here is my domain, or host on a certain domain - here are the explicit hosts that are allowed to send on our behalf". This would include your own mail servers, and any that may send "as" your domain (like Mailchimp, etc.).
SPF allows a pretty wide range of how to name these servers. You can name any "mx" record on the domain, an "a" record on the domain, any "ip4" or "ipv6" IP address, and other domain with the "include:" There's also "ptr" and "exists", but chances are you won't touch them.
Remember, setting up a PTR for "domain.com" will NOT authorize, say "mail.domain.com".
You set up a PTR for the @, AND any host / FQDN. Think things like "bounce.domain.com" would need it's own SPF record. Any domain or host/FQDN you send mail AS, you set up a separate SPF for, and setting one up for the @ (base domain) does NOT apply to, say "marketing.domain.com".
You are very correct, this is ONLY for SMTP going out.
You are basically saying "here is my domain, or host on a certain domain - here are the explicit hosts that are allowed to send on our behalf". This would include your own mail servers, and any that may send "as" your domain (like Mailchimp, etc.).
SPF allows a pretty wide range of how to name these servers. You can name any "mx" record on the domain, an "a" record on the domain, any "ip4" or "ipv6" IP address, and other domain with the "include:" There's also "ptr" and "exists", but chances are you won't touch them.
Remember, setting up a PTR for "domain.com" will NOT authorize, say "mail.domain.com".
You set up a PTR for the @, AND any host / FQDN. Think things like "bounce.domain.com" would need it's own SPF record. Any domain or host/FQDN you send mail AS, you set up a separate SPF for, and setting one up for the @ (base domain) does NOT apply to, say "marketing.domain.com".
You are very correct, this is ONLY for SMTP going out.
ASKER
mugojava: So we need to set up a SPF for smtp.ntua.gr, per the email we received and noted above?
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
mugojava: very well explained, thank you. I think since this is a midway SMTP server NOT managed by us, we'll be better off using the second SPF. If smtp.ntua.gr IP ever changes, then we'll have to go modify this again verse a DNS lookup.
Do you agree?
Do you agree?
Yes, if you have reservations on the smtp servers host name changing, using the include: will work.
ASKER
thank you