I host a spread of different domains that all use my (one) mail-server to send and receive mail. When sending mails, sometimes, my mail gets rejected by the receiving end, marked to the recipient as "suspicious" or simply heads straight for the spam folder.
Also, on the inbound, I get a load of "return receipts" from random victims of spam, where one of my domain names has been used even though the mail never touched my mail server.
I have been told, that both issues stems from the fact, that my SPF record is not set properly which i have been attempting to fix for quite a while now. Unfortunately my basic knowledge of the mechanisms behind the record and the syntax itself escapes me somewhat, which is why I'm looking here for help.
For the purpose of the following example, assume the following setup:
I have two domains: mydomain.com and myotherdomain.com.
Both domains have active subdomains that send and receive mail through my mailserver.
My mail server is named mail.mydomain.com
All running on the same physical server with the IP address: 85.81.xxx.xxx.
I have a semi-static IP-address with my ISP, e.g. it never changes but is per say not mine to call my own. A whois on 85.81.xxx.xxx produces 0x39Axxxx.dslpool.isp.com
Using the tool found at http://tools.bevhost.com/spf/ i end up with the following conclusion:
Email Origin : Pass - 85.81.xx.xx
resolves to
0x39Axxxx.dslpool.isp.com which then
again resolves to 85.81.xx.xx.
Sender Details : Pass -
myname#myotherdomain.net points to a
MX-record that points to my mail sever
at mail.mydomain.net.
Host Name HELO / EHLO : Fail -
mail.mydomian.not resolves to
85.81.xxx.xxx which resolves to
0x39Axxxx.dslpool.isp.com
So, the question is: If at all possible, how would I compose the SPF entries for mydomain.com and myotherdomain.com to disregard this conflict and allow my sent mails to appear valid when spf validated by the receiver?
Hoping for a response ...
Here you should have this SPF entry in your DNS v=spf1 +ip4:85.81.xxx.xxx -all for all your domains, and nothing more in your SPF string.
Make sure that you have such a DNS entry for mail.maydomain.com as well as mydomain.com,
because the SPF entry for mydomain.com is not valid for subdomain.mydomain.com.
If you have many subdomains,you may consider to have an SPF entry for *.maydomain.com. That will take care of all the domain tree that are sub or sub.sub or sub.sub.sub etc. domains of the domain mydomain.com.
Related
The domain s****g.nl has the following DMARC record:
"v=DMARC1; p=reject; rua=mailto:postmaster#s****g.nl,
mailto:dmarc#s****g.nl"
A valid SPF record for the sending mail server and none DKIM record.
The domain fo***de.com has a valid SPF and DKIM record.
Example 1
From: from#s****g.nl
To: thetoadres#mail.com
Result:
SPF: PASS
DKIM: FAIL
DMARC: PASS
Example 2
From: from#s****g.nl
Sender: response#fo***de.com
To: thetoadres#mail.com
Result:
SPF: PASS
DKIM: PASS
DMARC: FAIL
So when I send the email using a sender (on behalf of) the DMARC fails and the mail is not delivered.
Is there a explanation for this and maybe a solution to send emails on behalf of a domain which contains a DMARC reject policy and have a valid SPF for the sending mailserver?
Edit:
[Screenshot results...][1]
I have a feeling, it's failing on your ADKIM and ASPF Tests of DMARC. If SPF and DKIM passes, then it must be failing on both alignment tests.
Read this to understand more about Identifier Alignments
I seen several cases where there DKIM Validator is coded wrong and it will fail DMARC when it fails 1 alignment test, but both must fail according to the RFC Standards.
The only alignment tester I know about is this email tester, if you post the full headers of the sent emails. It'll be much easier to understand what might be wrong. You're only sharing part of the information and it's impossible to make a 100% accurate assessment. But I'm 80% confident the issue is with the alignment.
Based on the image you linked of your headers, I added an "a" to the beginning and "1" to the end so bots don't spam you.
Return-Path = response#afo***de1.com
DKIM Signature = d=afo***de1.com
From = info#as**g1.nl
So for ADKIM alignment to Pass the "from" domain must match the "d=" domain of the dkim signature
info#as**g1.nl <> afo***de1.com
For the ASPF Alignment to pass the "return-path" domain must match the "from" domain
afo***de1.com <> as**g1.nl
One of those need to match in order for DMARC to pass.
I've set up MX records as such:
5 # ALT1.ASPMX.L.GOOGLE.COM
5 # ALT2.ASPMX.L.GOOGLE.COM
10 # ALT3.ASPMX.L.GOOGLE.COM
10 # ALT4.ASPMX.L.GOOGLE.COM
1 # ASPMX.L.GOOGLE.COM
CNAME as such:
www xxxx.rhcloud.com
The problem is that xxxx.com does not resolve to www.xxxx.com in a web browser.
The second problem is that emails sent to xxxx.com return with "DNS Error: Address resolution of xxxx.ca. failed: DNS server returned answer with no data". And before, "The recipient server did not accept our requests to connect.".
Another thing was this. Not sure what that is.
I've seen some hints on the internet to set up an A record to route # to the IP of the server, but rhcloud dosen't have one IP, I don't think.
I'm completely out of my depth here. I just want my google apps emails to work, and website to direct trafic to my rhcloud server.
You can't set your root domain as CNAME, only subdomain can be CNAME.
Root domain must have A-record if you want correct redirect to www.yoursite.com in web browser.
I've seen some hints on the internet to set up an A record to route # to the IP of the server, but rhcloud dosen't have one IP, I don't think.
Symbol "#" in DNS zone means "root domain without subdomains, so this two record are equal:
NAME TYPE VALUE
--------------------------------------------------
someexample.com. A 55.33.11.22
# A 55.33.11.22
I don't know how openshift works, but looks like you can have only subdomain directed to your xxx.openshift.com application.
Issues with MX records in is unrelated to first question and I can't say what actually wrong.
Will be better if you show your real domain name so I can look on real zone configuration.
So would username#gtld be a valid email? As a practical example google is purchasing the gTLD "gmail". Obviously they can associate A records with that permitting you to just type http://gmail/ to access the site. But, are there any specs that prohibit them from associating MX records with that as well, allowing folks to give out an alternative address username#gmail?
I ask because I want to make sure our email validator is future proof and technically correct.
I think I answered my own question. Section 3.4.1 of rfc5322 which defines a valid email address states:
addr-spec = local-part "#" domain
[...]
domain = dot-atom / domain-literal / obs-domain
[...]
The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [RFC1034], [RFC1035], and [RFC1123]. In the domain-literal form, the domain is interpreted as the literal Internet address of the particular host.
"gmail" would be a valid domain and host name and thus someone#gtld is a valid email address.
CentOS 6, Postfix, OpenDKIM
Have correct DNS records
Sending email using PHP mail() to appmaildev.com - returns auth-report:
SPF result: Pass
DKIM result: fail (wrong body hash: MpaYoPlKy8H4qX8syH3dOM1gPr6spBK5/INxl2X2uNs=)
Tried different solutions - no result
Any ideas?
There are several causes for these two errors: the message may have been modified (perhaps by a mailing list or forwarder) in transit; the signature or hash values may have been calculated or applied incorrectly by the signer; the wrong public key value may have been published in DNS; or the message may have been spoofed by an entity not in possession of the private key needed to calculate a correct signature.
Any way you can check your DKIM entry for your MAIL-FROM domain here
I know this is an older post but, I ran into this issue yesterday. If you are using MailScanner for anti-spam efforts, try disabling the watermarking feature. I found the added watermark headers were invalidating DKIM hashes. Disabling the watermarks allowed the DKIM hashes to be valid. Yahoo was bouncing mail due to this.
As the above poster mentioned, I also had this problem. We use a windows server as our mailserver and we have antivirus installed on it.
It was setup to scan each outgoing message, but this changed the hash / body of each mail, thus failing the DKIM check.
So if you have this wrong body hash error, make sure you don't scan outgoing mails :)
What is SMTP Envelope and SMTP header and what is the relationship between those? How do I extract them with Perl?
An SMTP message contains a set of headers such as From, To, CC, Subject and a whole range of other stuff.
An SMTP Envelope is simply the name given to a small set of header prefixed to the standard SMTP message when the message is moved about by the Message Transport Agent (ie. the SMTP server). The most common envelope headers are X-Sender, X-Receiver and Received.
For example Microsofts SMTP Server will add the X-Sender and a series of X-Receiver headers to the top of a message when it drops the message into its Drop folder. There will be one X-Receiver for each post box that matches the domain the Drop folder is for.
Another example is SMTP servers add a Receive: header when it receives a message from another SMTP server. This header gives various details of the exchange. Hence most emails on the tinternet once arrived at the final destination will have a series of Receive headers indicating the SMTP server hops the message took to arrive. Usually servers remove the X-Sender, X-Receiver headers when the message is finally moved to a POP3 mailbox.
Accessing Headers
On the windows platform the only way I've found to access the envelope headers is to simply open and parse the eml file. Its a pretty simple format (name: value CR LF).
Again on the windows platform the main set of message headers and body parts can be accessed using the CDOSYS.dll COM based set of objects. How you would do this on other platforms I don't know. However the header format is quite straight forward as per the envelope headers, its accessing the body parts that would require more creative coding.
The envelope is the addressing information sent to the server during the initial conversation via the "MAIL FROM:" and "RCPT TO:" commands.
The SMTP header is the collection of header lines which are sent after the DATA command is issued.
How you find them is dependant on how/where you're getting the message from, and we'd need a lot more clues to attempt to answer that.
You can actually think of three different things here. There are the directives that were exchanged between the SMTP MTAs (during each hop the message took) ... the headers that were generated by the MUA and headers that were added (or modified) by MTAs along the route that a given message traversed.
The "envelope" refers to the information provided to the MTA (normally the most recent or final destination MTA). The sender includes a set of headers after the DATA directive in the SMTP connection (separated from the body of the message by a blank line ... but double check the RFC if that's specifically supposed to be a CR/LF pair). Note that the local MTA may add additonal headers and might even modify some headers before storing or forwarding the message.
(Normally it should only add Received-by: headers).
Some MTAs are configured to add X-Envelope-To: and/or X-Envelope-From: headers. Some of them will still filter the contents of these headers (for example to prevent leakage of blind copies). (Senario: the original MUA had a BCC: line directory that a number of people be copied on the message with their names all appearing to one another in the CC: headers; for each recipient domain (MX result) the MTA will only issue RCPT TO: for only the subset of addresses for which the host if the appropriate result (its own hub, smarthost, or any valid MX for the target) --- thus any subsets of recipients who share an MX with each other would see leakage in the X-Envelope-To: headers generated by MTAs that were sloppy about the handling of this detail).
Also not that an Envelope-From line would only contain a host/domain name as supplied by the HELO FROM: or EHLO FROM: directives in the SMTP exchange. It cannot be used as a return address, for replies for example.
For Perl email related stuff have a look at the Perl Email Project.