If you are going to begin using e-mail on a sub-domain of an existing zone, you do not need to do anything special to register the sub-domain. If this is a new domain, it needs to be publicly registered first. The examples used here-in will be a mail domain subordinate to example.com. If you are performing the tasks for a new zone, create the new zone first.<\/p>\n
To allow e-mail exchange with a domain, create MX record(s). For a third party vendor, they need to tell you what their mail exchangers are<\/em>. For internally hosted services, define your own:<\/p>\n example..com\u00a0 MX preference = 10, mail exchanger = primarymailhost.example.com<\/p>\n example.com\u00a0 MX preference = 20, mail exchanger = secondarymailhost.example.com<\/p>\n example.com\u00a0 MX preference = 110, mail exchanger = fallbackmailhost.example.com<\/p>\n Within Infoblox, you need to be using the external<\/em> DNS view. You can<\/em> create matching records internally \u2013 we tend not<\/em> to create internal MX records as it prevents internal multi-mailer infections from routing messages. In the proper zone, click Add => Record => MX Record<\/p>\n The mail destination will be the subzone (here we are exchanging e-mail with @ljrtest.example.com)<\/p>\n Save this change and create the other MX records. ** You need to clue the servers into the fact this domain is now valid. ** On each server, edit \/etc\/mail\/access and add<\/p>\n Ljrtest.example.com\u00a0 RELAY<\/p>\n If you want to use the virtusertable to map addresses within the domain, you also need to add the domain name to \/etc\/mail\/virtuser-domain<\/p>\n Finally, you need to send the mail somewhere. <\/em>Edit \/etc\/mail\/mailertable and set a relay destination of somewhere that knows about the domain and is processing mail for it (is that our Exchange server? Someone else\u2019s Unix server? An acquired company\u2019s mail server? \u2026 depends on what you are trying to do!)<\/p>\n rushworth.us\u00a0\u00a0\u00a0 relay:[10.5.5.85]<\/p>\n Save, make, and restart sendmail \u2026 now you have a fully functional external email domain.<\/p>\n Now secure it \u2013 that means adding sender policy framework (SPF), domain key (DK), and domain key identified mail (DKIM) records.<\/p>\n SPF and SenderID Records<\/strong><\/p>\n There are both sender policy framework (v1) and SenderID (v2) records \u2013 you can create both. Not too many people use SenderID anymore, but I invariably end up finding the\u00a0one<\/em> guy who is evaluating mail validity purely on SenderID when I create just the SPFv1 record.<\/p>\n In InfoBlox, select Add => Record => TXT record. The mail destination from the MX record needs to be put in the \u201cName\u201d field. Then the text value \u2013 what is that?<\/p>\n Quick answer is it depends. A SPF record lists all mail servers that should<\/em> be sending e-mail for a domain. Is that just our MX servers? The MX servers plus the netblocks for the internal relays? Some third-party vendor?<\/p>\n Our MX servers and a few netblocks would be:<\/p>\n SPF V1: “v=spf1 mx ip4:1.2.3.4\/26 ip4:2.3.4.5\/23 ?all”<\/p>\n SPF V2: “spf2.0\/pra mx ip4:1.2.3.4\/26 ip4:2.3.4.5\/23 ?all”<\/p>\n If there is a third-party vendor, they may provide an include statement for our SPF record \u2013 this is a way of referencing an external company\u2019s SPF record within your own. As an example, you might see \u201cinclude:mktomail.com\u201d in an SPF records where Marketo sends mail on the company’s behalf.<\/p>\n The final bit \u2013 we use ?all which means these may not be all of the servers sending mail on our behalf \u2013 we are not making an assertion beyond saying the listed sources are<\/em> good. You may see vendors requesting \u201c~all\u201d which is a soft fail — still allows mail to pass if the sender does not match the list. The strictest is \u201c-all\u201d which fails mail coming from any source not in the list.<\/p>\n Does it matter? Depends \u2013 if a recipient has configured their mail servers to reject mail based on SPF and <\/em>you use -all \u2026 mail from servers not on the list will be rejected. Not a lot of companies are thusly configured, though \u2026 so there\u2019s not a whole lot of effective difference.<\/p>\n