Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a WordPress site that needs to send notifications to an email address. I would like the from field from this emails to be an address on my client's domain.

I dont know much about email security and antispam systems, but I guess that we would need to do some further configuration my client's domain so it doesnt get classified as spam, is that right?

So far I have done a few tests, without applying any configuration to the client's domain, and our company Exchange server blocks it, but gmail accepts it and doesnt even classify it as spam. I dont really understand how gmail accepts it: following this logic, I could send emails from any address I use in the site's configuration and Gmail would consider it safe?

So I would like someone explaining to me how this works, and what is a proper configuration for this situation.

share|improve this question
    
Check SPF records for DNS –  JP Hellemons Dec 21 '11 at 11:06
add comment

1 Answer

up vote 2 down vote accepted

You need to start with a basic understanding on how email is sent/received. I'll walk you through how a typical corporate email is sent and ultimately reaches its destination in as much (relevant) detail as I can. For example, I will explain where a DNS query is used but will not discuss the intricacies of how DNS works and what would happen if the primary DNS server didn't respond, etc. in order to stay on topic.
Skip to step 9 for anti-spam specifics.

In order to create the most relevant information I can, I'll try to keep things general by avoiding any specific applications.

1) A user sitting a PC in a corporate network types an email from wiley@acme.com into their mail client to bob@contoso.com and clicks 'send'.

2) The mail client will attempt to send the mail to the preconfigured mail server. Most often, the mail server is configured with a DNS name.

3) The PC looks in its DNS cache for the mail server. If the IP is not in cache, the PC send a DNS query to its primary DNS server to obtain the IP address of the mail server.

4) Now that the PC has the IP of the mail server, it will start to think about making a connection to it. Therefore, it looks at its IP address and subnet mask to see if it is in the same subnet as the mail server. If it isn't, it checks its local routing table ('route print' on windows) to see if there is a specific route to the mail server. If not, it will send the packet to its default gateway. (It followed this same process in order to contact the DNS server in step 3 too by the way)

5) The PC now knows where to send the packet so it creats a new connection to the mail server and sends the email to the default gateway who routes it to the mail server.

6) The mail server now has the task of delivering the message. The server might deliver mail itself but more likely, it will forward Internet-bound email to another device that will check the message against security policies for things like viruses, spam, data loss prevention, size, content, it may add a disclaimer to the message, etc.

7) After checking out ok against policies, the message needs to be delivered. The server sending the message knows that the destination is bob@contoso.com but it needs to know the IP address of the server where it needs to send the message. It performs a DNS query using root hints to get a list of .com DNS servers. Root hints servers are at the highest level of the DNS heirarchy on the Internet. Root Hints servers know which servers handle .com, .net, .org, .etc. Those servers then know who handles hotmail.com, google.com, and so on and so forth. Getting back to the task, the corporate DNS server now has a list of .com DNS servers. It then sends another query to a .com DNS server looking for contoso.com and gets a response of Contoso's public DNS server. A third DNS query is now sent to Contoso's public DNS server asking for MX (Mail Exchanger) records for the contoso.com domain. The contoso.com DNS server responds with those records and any preferences assigned. Finally, the corporate DNS server replies to the mail server with the IP addresses of contoso.com's mail servers. Phew!

8) The mail server at acme.com chooses the MX record with lowest preference and opens a connection to TCP port 25 on that server. This connection must be allowed to traverse firewalls at both acme and contoso.

9) Depending on the type of anti-spam device that is in use at contoso, several checks can now take place before the message is even sent. Contoso's Antispam device can check the reputation of the IP address that is sending the message (Acme's public IP) against databases such as senderbase, spamhaus to see if it is a known spammer. If there is a match, the antispam device will most likely end the connection. The idea behind all these checks is to verify that the sender is not a spammer and that the message did in fact come from the actual sender rather than being spoofed (forged). So, if the connection is ok so far, acme will send contoso a helo with a greeting that identifies itself as mail1.acme.com. Contoso might then perform reverse greeting and reverse DNS checks. In a reverse greeting check (hotmail does this), contoso will perform its own DNS queries to look up mail1.acme.com and will open a connection to that server. It will then compare the greeting it receives from this known correct server to the greeting it was given eariler since the sending box is claiming to be mail1.acme.com. If the greetings don't match, mail can be rejected, throttled and your senderbase score will drop. Next, a reverse DNS check is performed. The mail server at acme.com performs a DNS lookup on the IP address with which is has just formed a connection. Reverse DNS is maintained by the Internet Service Provider for a given block of IP Addresses. The reverse IP should resolve to the name of the mail server namely, mail1.acme.com. If the reverse dns does not match, mail can be rejected, throttled and your senderbase score will drop. Finally, the receiving domain might perform an SPF record check. An SPF record lists the names and IP's of servers that are authorized to send mail for a given domain. So, if acme.com is concerned about people forging mail from them, they will add SPF records to their own DNS listing their own mail servers. If someone else tries to send mail from acme.com from an IP not listed in the SPF records, contoso will reject the message.

10) Assuming acme.com has everything setup correctly and everything checks out, the server at contoso will respond with a 220 or "go ahead". The mail server at acme now sends the recipient information. Before proceeding any further, the receiving mailserver at contoso will then lookup the recipient to verify that he/she exists. If not, the connection ends.

11) Sender information is sent which again is compared with the sending domain to make sure there's no switching going on.

12) Next, size and content is evaluated by contoso's anti-spam products, the message is scanned for viruses, etc and is finally delivered to contoso's mail server and the recipient's inbox.

And all you had to do was click "Send"! :-)

Source

share|improve this answer
    
Wow, I can't thank you enough for this answer. This has helped me a lot and it is a really interesting read. Thank you man! –  ooops Dec 21 '11 at 13:57
    
No problem. I didn't mention this but many anti-spam products tend to block mail that is sent "from" their own domain. So if a message comes into the acme.com domain from the outside world and is "from" someone@acme.com, most products will block this by default so it might be better to use another address. –  Paul Ackerman Dec 21 '11 at 20:27
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.