"My website is up and running on www.example.com and I am sending automated emails from >my email address [email protected]."
When these automated emails are sent from your website or application, it sounds like they are being sent using their own mail server without any SMTP authentication. For example, a website may send out user registration email confirmation messages using sendmail or postfix mail server software which is commonly installed on web servers for this purpose, however those who send spam or spoofed email messages use the same techniques and can also claim to be sending email from [email protected]. With some configuration, your website could be sending authenticated emails, i.e. instead of using the built-in mail server software, the website connects to your domain's main SMTP server (could be Exchange or Office365 or Google etc, other mail server brands exist), authenticates with a username and password, just as you would if you were using an email client application on your phone or webmail, and then it sends the email.
"No DMARC Record found for sub-domain. Organization Domain of this sub-domain is: example.com Inbox Receivers will apply example.com DMARC record to mail sent from www.example.com"
In the absense of a sub-domain DMARC record, the main record for the domain will apply. Unless you are using email addresses like [email protected] this is not likely to be an issue. You could ensure there will be an SPF fail in this case by have a wildcard SPF record to cover any subdomains spoofers may think of, for example: v=spf1 -all, and enter * as the hostname for this record. This will not interfere with the SPF record you have created for the @ which covers your normal use of email for the domain, email addresses such as [email protected].
"A DMARC record is defined, but there are some issues with the configuration that may impact security, visibility, and deliverability for email sent from this domain."
Without more investigation it will be difficult to tell exactly which issue this may be referring to, however it might be as simple as the fact you're specifying an email address with the same domain name for the reports to be sent. If there are email delivery issues with the domain example.com your reports about it may not be received at [email protected]! Perhaps setup [email protected] or other different domain for processing your DMARC reports.
"DMARC is not at enforcement for example.com. Anyone can send messages purporting to be from addresses on this domain or its subdomains."
This simply means you have p=none or p=quarantine at the moment. The first is ideal for when you're just getting started and need some oversight as to what's going on without wanting to cause problems unnecessarily. The second is a good mid-way point to start seeing messages quarantined (moved into Junk folders) when you're testing the effectiveness of which ones it blocks and doesn't. Eventually the aim for most organisations will be to set this to p=reject in order to ensure the messages simply get dropped and are never received. Since DMARC forensic reports are rarely implemented at present you might actually be safer going for quarantine until you are entirely satisfied that those being quarantined includes no genuine messages. Some tweaking may be required before you move to p=reject. The message you're seeing doesn't mean you've done anything wrong, just that your implementation is at the early stages.
none. This essentially means that no action (except reporting) is taken on spoofed mails based on the DMARC policy.v=DMARC1;p=reject;pct=100;rua=mailto:[email protected];ruf=mailto:[email protected]instead? Because I keep receiving automated emails from yahoo and gmail in daily basis and gmail shows my email as unauthenticatedp=rejectwill reject spoofed mails. But you should probably check the DKIM reports you've got so far to make sure that only mails you want to have rejected are classified as unauthenticated so that no expected mails get rejected.