#SMTP AUTH CONFIGURATION
smtpd_sasl_auth_enable = yes
#smtpd_client_message_rate_limit = 5
#smtp_sasl_auth_enable = yes
#smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
#smtp_sasl_security_options =
broken_sasl_auth_clients = yes
smtpd_sasl_local_domain = $myhostname
smtpd_reject_unlisted_recipient = no
smtpd_reject_unlisted_sender = no
#####

Example:
eg. rerouting all emails of destination domain mydomain.com via a relay server (relay.myserver.com)

(Email ==> Email Accounts / Email Routing)
Select ‘Add new Transport’
Fill in the fields:
Server: (Select the server)
Domain: mydomain.com
Type: (select smtp)
No MX lookup: (leave unchecked)
Destination: relay.myserver.com
Sort by: 1
Active: (Checked)

(Email ==> Global Filters / Relay Recipients)
Select: ‘Add new relay reciepient’

Fill in the fields:
Server: (Chose the server)
Relay recipient: @mydomain.com
Active: (Checked)

Command to verify the DNS record : dig _dmarc.saic.it any

Description

Email Security: What is DMARC record and how to create it on DNS server.

Prerequisites:

• Creating SPF record: https://www.sonicwall.com/en-us/support/knowledge-base/170504417772166
• Creating DKIM record: https://www.sonicwall.com/en-us/support/knowledge-base/170504710515852

Before creating DMARC records it’s a good idea to test DKIM and SPF. Testing can be found here: https://dmarcguide.globalcyberalliance.org/#/

Resolution

Creating a DMARC record

Create the record
DMARC is designed to give receivers of email better judgment control  based on sending domain reputations.  It provides a platform where the sending side can publish policies to improve effectiveness against spam and phishing, in effect building domain reputations. This helps to provide guidelines on how to address messages that do not align according to those policies published by the sending domains.
  
DMARC was aimed at:
Reducing false negatives
Provide authentication reporting
Apply sender policies at the receiving end
Reduce phishing
Be scalable
  
In order to get started with DMARC, the sending domain needs to have an SPF and DKIM record published. Once the SPF and DKIM records are in place, you can configure DMARC by adding policies to your domain’s TXT records (the same way in which you published your SPF and DKIM records).  Your TXT record name should read something similar to “_dmarc.your_domain.com.”  Please replace the “your_domain.com” with your own domain.
 
As DMARC policies are published as TXT records, it defines what an email receiver should do with non-aligned mail it receives.

A DMARC record’s name when creating a TXT record is “_dmarc” which forms a TXT record such as _dmarc.mydomain.com or _dmarc.mydomain.net etc

An external guide/wizard on creating DMARC records: https://dmarcguide.globalcyberalliance.org/#/dmarc/

 Example:
“v=DMARC1;p=reject;pct=100;rua=mailto:[email protected]”  
 
 In this scenario, the sender defines the policy as such that the receiver outright rejects all non-aligned messages and sends a report about the rejections to a specific email address. If the sender were to use the “quarantine” setting in the policy, it would look like:
 
“v=DMARC1;p=quarantine;pct=100;rua=mailto:[email protected]” 

and would request the action to quarantine on the receiving end of the message. In the next example, if a message claims to be from your domain.com and fails DMARC, no action is taken. Instead, these messages will then show up in your daily aggregate report sent to
 
 “v=DMARC1; p=none; rua=mailto:[email protected]_domain.com” 

Here is a sample where the message fails DMARC, then quarantines it 5% of the time.
 
 “v=DMARC1; p=quarantine; pct=5; rua=mailto:[email protected]_domain.com” 

In this sample, the policy is set to reject the message 100% of the time and send the daily report to the specified address of [email protected]_domain.com.
 
“v=DMARC1; p=reject; rua=mailto:[email protected]_domain.com, mailto:[email protected]_domain.com”
  
 DMARC records follow the extensible “tag-value” syntax for DNS-based key records defined in DKIM. The following chart illustrates some of the available tags:
  
Common tags used in DMARC TXT records:
 

Only the v (version) and p (policy) tags are required. Three possible policy settings are available:

• none – Take no action. Only log the affected messages in the daily report.
• quarantine – Mark affected messages as spam.
• reject – Cancel the message at the SMTP layer.  

 
Alignment mode refers to the analysis which sender records are compared to SPF and DKIM signatures. There are two possible values being presented, relaxed “r” or strict “s”. Relaxed allows for partial matches such as subdomains while strict requires an exact match.
Be sure to include an email address with the optional rua tag to have the daily reports sent to that address.
 
Example report
The daily reports are sent in XML format. They provide feedback informing you of the sending source IP addresses that have been sending out on your domain’s behalf.  This helps in determining which sources are valid or not. As a result, this assists in more effective deployment of your SPF and DKIM records.
Here is an example of a daily aggregate report. The judgement result is shown along with the source IP addresses and the action taken.
  
<record>
 <row>
 <source_ip>207.126.144.129</source_ip>
 <count>1</count>
 <policy_evaluated>
 <disposition>none</disposition>
 </policy_evaluated>
 </row>
 <identities>
 <header_from>stefanomail.com</header_from>
 </identities>
 <auth_results>
 <dkim>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 <human_result></human_result>
 </dkim>
 <spf>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 </spf>
 </auth_results>
 </record>
 <record>
 <row>
 <source_ip>207.126.144.131</source_ip>
 <count>1</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <reason>
 <type>forwarded</type>
 <comment></comment>
 </reason>
 </policy_evaluated>
 </row>
 <identities>
 <header_from>stefanomail.com</header_from>
 </identities>
 <auth_results>
 <dkim>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 <human_result></human_result>
 </dkim>
 <spf>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 </spf>
 </auth_results>
 </record> 
 
Here is an example of how to specify the optional size limit argument and set it to 10 MB.
“v=DMARC1; p=none; rua=mailto:[email protected]_domain.com!10m”
  
Deploy slowly 
As the DMARC specification takes into consideration that scaling out the deployment may be challenging for some organizations to do at once, there are a number of built-in methods for “throttling” the DMARC processing so full deployment can be done in increments over time.

• First thing to do is monitor your traffic and reports. Assess where your vulnerabilities are (where messages are being delivered without being digitally signed or are coming from invalid source IP addresses) and address them through SPF and DKIM records.
• As you monitor your daily aggregate reports and get to a place where you are comfortable with the results, you can change the action on your policies to start to quarantine. You do this by changing your TXT record using DMARC to use the “quarantine” action. Continue to monitor your daily reports
• Once you have been monitoring your traffic and daily reports for some time and feel comfortable with the sources seen sending traffic on behalf of your domain and they are all being digitally signed, you can move forward with the next step in changing the policy to use the “reject” tag to fully deploy DMARC in its entirety. Monitoring your reports and your spamfeed is an essential part of maintenance for DMARC accuracy.

Also worth noting, the optional pct tag can be used to sample your DMARC deployment in increments as well. Since 100% is the default, passing “pct=20” in your DMARC TXT record results in one-fifth of all messages affected by the policy actually receiving the disposition instead of all of them. This setting is especially useful once you elect to quarantine and reject mail. Start with a lower percent to begin with and increase it every few days.
So a conservative deployment cycle would resemble:

1. Monitor all.
2. Quarantine 1%.
3. Quarantine 5%.
4. Quarantine 10%.
5. Quarantine 25%.
6. Quarantine 50%.
7. Quarantine all.
8. Reject 1%.
9. Reject 5%.
10. Reject 10%.
11. Reject 25%.
12. Reject 50%.
13. Reject all.

When you are ready to complete the DMARC deployment, remove the percentages from your policies so that the full action of “quarantine” and “reject” is now functioning at 100%. As always, monitor your daily reports.
Recap DMARC deployment.

1. Deploy SPF and DKIM records for your domain.
2. Confirm that all sending MTA’s on behalf of the specified domain are aligning the appropriate identifiers appropriately.
3. Publish DMARC record using the “monitor” flag and specify rua value to receive daily aggregate reports.
4. Assess vulnerabilities from the daily reports and adjust SPF and DKIM accordingly. Make changes to your mailstreams as needed.
5. Change DMARC policy flags to “quarantine” and then eventually to “reject” as you see fit.

For further reference, you can go to:
http://dmarc.org/overview.html
http://dmarc.org/specification.html

Download latest epel-release rpm from
http://download-ib01.fedoraproject.org/pub/epel/6/x86_64/
Install epel-release rpm:

rpm -Uvh epel-release*rpm

Install bsd-mailx rpm package:

yum install bsd-mailx

with mailx you can delete the messages as follow (as root):

bsd-mailx

…
& d *
& q

and c.email_address NOT REGEXP ‘[-a-z0-9~!$%^&=+}{\\’?]+(\.[-a-z0-9~!$%^&=+}{\\’?]+)@([a-z0-9_][-a-z0-9_](\.[-a-z0-9_]+)*\.(aero|arpa|biz|com|coop|edu|gov|info|int|mil|museum|name|net|org|pro|travel|mobi|[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?’

Sicurezza OTP token